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?
replynegative_zero 2 hours ago
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
replyBlackRabbit1 12 minutes ago
CoMaps behaves very very weirdly on GrapheneOS. Same with OrganicMaps.
replyOsmand and GMaps are working fine.
Waze is almost melting the poor thing. Beside of that working fine.
ThePowerOfFuet 3 minutes ago
I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
replyGroxx 38 minutes ago
Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
replypjmlp 2 hours ago
Maybe the actual solution is to improve, replace the application.
replyizacus 2 hours ago
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
replymohamedkoubaa 2 hours ago
There needs to be a wall of shame for apps that abuse hardware owned by users
replyyjftsjthsd-h 2 hours ago
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
replyperching_aix 47 minutes ago
That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
replyperching_aix 2 hours ago
If you have two apps, both maps...
reply> 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?
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