> 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?
OsmAnd has a large legacy C++ codebase with a lot of memory corruption bugs. Many memory corruption bugs have been found and reported by GrapheneOS users. It isn't yet clear if the performance issues the OpenGL renderer has with hardened_malloc are caused by it making too many allocations or actual bugs.
The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.
perching_aix · · focus · HN ↗
> 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 · · focus · HN ↗
RedComet · · focus · HN ↗
grapheneos · · focus · HN ↗
The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.