GrapheneOS – When an app is slow
49 points by speckx 3 hours ago | 21 comments

hadi77ir 8 minutes 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?
reply
negative_zero 2 hours ago
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
reply
BlackRabbit1 12 minutes 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.

reply
broodbucket 2 minutes ago
Waze works perfectly fine for me
reply
ThePowerOfFuet 3 minutes ago
I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
reply
Groxx 38 minutes ago
Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
reply
pjmlp 2 hours ago
Maybe the actual solution is to improve, replace the application.
reply
izacus 2 hours ago
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
reply
palata 4 minutes ago
Maybe... legacy?
reply
Groxx 36 minutes 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.
reply
izacus 12 minutes ago
That's trivially provable as false.
reply
nvme0n1p1 8 minutes ago
If so, I'd love to know which OEM you're thinking of who ships an Android distro more secure than GrapheneOS.
reply
pjmlp 36 minutes ago
Because they cut costs on hardware and not all ship MTE enabled ARMs.
reply
mohamedkoubaa 2 hours ago
There needs to be a wall of shame for apps that abuse hardware owned by users
reply
yjftsjthsd-h 2 hours ago
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
reply
pjmlp 34 minutes ago
The AOSP memory allocator is seldom the one used by OEMs.
reply
perching_aix 47 minutes ago
That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
reply
perching_aix 2 hours ago
If you have two apps, both maps...

> The reason behind it is the hardened memory allocator, which seems to create a significant overhead for Osmand. That might be because scrolling a map requires constant loading and discarding of data.

... is this really the right hunch, over e.g. the OpenStreetMaps app lacking in discipline with its heap allocations?

reply
himata4113 2 hours ago
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
reply
RedComet 13 minutes ago
The core is C++ afaik.
reply