GrapheneOS – When an app is slow | Hacker News

GrapheneOS – When an app is slow blog.wirelessmoves.com

85 points•speckx•2 days ago•57 comments•

57 comments

Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.

BlackRabbit12 days ago

CoMaps behaves very very weirdly on GrapheneOS. Same with OrganicMaps.

Osmand and GMaps are working fine.

Waze is almost melting the poor thing. Beside of that working fine.

grapheneos1 day ago

CoMaps and Waze definitely work well on GrapheneOS. There's a known performance issue experienced by some users with the OsmAnd OpenGL renderer which can be worked around disabling hardened_malloc. We could likely provide a performance vs. security toggle for hardened_malloc to avoid it, but we also plan to continue optimizing the default high security mode.

subscribed2 days ago

Osmand and OrganicMaps work flawlessly for me. Waze on 6 (not pro), works better than on my 9 Pro.

gunalx2 days ago

Have had no noticable problems with organic maps.

pizzaiolo2 days ago

Weirdly how? CoMaps seemingly works fine out of the box on my device

methuselah_in1 day ago

comaps and organic maps shares some of the same codebase right?

Self-Perfection2 days ago

And yet problems exist. Live Updates are not rendered if both OsmAnd V2 rendering and hardened memory allocator are enabled: https://github.com/osmandapp/OsmAnd/issues/20190

Groxx2 days ago

Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...

grapheneos1 day ago

The hardened_malloc configuration in GrapheneOS is the security-focused configuration. OsmAnd ends up acting as a malloc microbenchmark in certain configurations. Users have reported it only happens with the OpenGL rendering mode and it doesn't seem to happen for everyone.

GrapheneOS can provide a performance vs. security toggle for hardened_malloc for these rare cases but it rarely comes up as relevant.

WalterGR2 days ago

https://news.ycombinator.com/item?id=45358216

Groxx2 days ago

I mean OsmAnd - other mapping apps don't slow down anywhere near this much.

OSM-rendering apps are a fair bit more computationally-expensive than many apps, so I do expect them to show the allocator's cost more, but OsmAnd stands out quite starkly against every other app on my phone.

pjmlp2 days ago

Maybe the actual solution is to improve, replace the application.

mohamedkoubaa2 days ago

There needs to be a wall of shame for apps that abuse hardware owned by users

yjftsjthsd-h2 days ago

How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.

izacus2 days ago

Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.

grapheneos1 day ago

The hardened_malloc project has performance vs. security configuration. It's used in a very security-oriented configuration in GrapheneOS. GrapheneOS could offer a performance vs. security toggle for this but hasn't yet included one since there are rarely apps with any noticeable performance difference. Android apps are mostly written in Java/Kotlin where it makes no difference. There are often specific uses of optimized C, C++ or Rust code where it makes little difference. It's rare for an app to be heavily impacted by malloc performance as if it's a malloc microbenchmark, and even in that case the overhead is typically quite reasonable. OsmAnd is doing something very strange in a certain configuration.

Groxx2 days ago

The fairly obvious answer here is "OEMs don't care about security because very few people will pay for it, either with $ or time". Benchmaxxing sells better.

pjmlp2 days ago

Because they cut costs on hardware and not all ship MTE enabled ARMs.

palata2 days ago

Maybe... legacy?

aucisson_masque2 days ago

What is the point of this hardening feature if you got to disable it ?

You can tweak Android as much as you want, the OS was not made to be private nor secure. App developers will never check if it breaks the grapheneos memory allocating feature (amongst others) so by default you disable it.

Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.

grapheneos1 day ago

> What is the point of this hardening feature if you got to disable it ?

It doesn't have to be disabled. Most users are saying OsmAnd runs fine for them with the default of hardened_malloc being enabled. There was no need to disable the other hardening features. A subset of users are experiencing slow performance in the OpenGL rendering mode with hardened_malloc enabled. It's likely due to the implementation in the app doing something quite inefficient which hasn't yet been identified. The hardened_malloc configuration in GrapheneOS is heavily oriented to security and has more overhead than the lite configuration. We could offer a performance vs. security mode for it but it usually makes no major difference and has a toggle for any case it does.

progval2 days ago

It's meant to protect apps against their own bugs. It's an improvement to be enabled by default and disabled for the few apps where it's an issue.

epihelix2 days ago

> Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.

?? GrapheneOS does respect horrid play integrity (it provides basic integrity only).

Not that this has any bearing on how an app runs performance-wise.

aucisson_masque1 day ago

Before looking at how an app run “performance wise”, you got to be able to run it. That’s my point.

Basic play integrity doesn’t mean much, more and more applications are requiring full play service integrity.

hadi77ir2 days ago

I wonder if a website using leaflet.js has better or worse performance in the said case. If it does better, then maybe the problem is on OsmAnd's side?

speedstyle1 day ago

Leaflet is (generally) for streaming image tiles, OsmAnd renders a set of geographical features itself. But yes, it could do so more efficiently

Read the full thread on Hacker News →

57 comments

Related stories