> 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•23m ago
Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
pjmlp•29m ago
Maybe the actual solution is to improve, replace the application.
mohamedkoubaa•26m ago
There needs to be a wall of shame for apps that abuse hardware owned by users
yjftsjthsd-h•14m ago
How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
izacus•21m ago
Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
negative_zero•13m ago
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
perching_aix•31m ago
> 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•23m ago