• General

  • Performance cost of various security features

Just to be clear I'm not complaining or advocating against them (that would be silly), this is just an open discussion for tips and feedbacks.

GrapheneOS provides great documentation, but as it stands out, Secure Spawning is the only security feature that provides a clear layman's terms explanation about it's everyday use impact (app "cold" load is a bit longer).

I just found out Osmand runs significatively better with Hardened Memory Allocator disabled.
I'm wondering if it's because Osmand, by its very nature, use a lot of memory or something else.

  • de0u replied to this.

    I can't comment on the performance of OsmAnd specifically as I don't use it. As for the general performance of GrapheneOS, it should be expected that security features come at the cost of some performance. Whether these 'tradeoffs' are noticeable in day-to-day use is another story and the reason Secure Spawning is specifically mentioned probably stems from the fact that the delay is quite obvious in normal use. You can read more about hardened_malloc specifically here which acknowledges the inverse relationship between performance and security.

    Thank you I red that doc. It would awesome to have access to those Hardened_malloc sub tweak, obviously disabling it entirely is not ideal.

    In any case I blamed the not so stellar Tensor performance for Osmand running like a dog, but Hardened_malloc was definitely the issue, maybe dev could exclude that app by default, just like Gcam.

    • phnx replied to this.

      Canardo_Sanchez I just found out Osmand runs significatively better with Hardened Memory Allocator disabled.

      Thanks for the report! I wonder if the OsmAnd project might be interested in mentioning that to users.

      Canardo_Sanchez I'm wondering if it's because Osmand, by its very nature, use a lot of memory or something else.

      Offhand my hunch would be that it pulls lots of items from map databases into memory as independent items because it will want to dump them once they are no longer relevant. So it might not be the total amount of memory as much as the frequency of allocate/free calls.

      I wonder if it's faster on a device with MTE?

          Osmand indeed aggressively dump tiles or parts of map outside of screen boundary, only to reload them as soon as necessary. Maybe a performance choice/tweak that is ultimately prone to backfire.

          Canardo_Sanchez Thank you I red that doc. It would awesome to have access to those Hardened_malloc sub tweak, obviously disabling it entirely is not ideal.

          Funny enough this was mentioned by a developer of GrapheneOS in an open issue about this poor performance in OsmAnd related to hardened_malloc. See here.

          Canardo_Sanchez In any case I blamed the not so stellar Tensor performance for Osmand running like a dog, but Hardened_malloc was definitely the issue, maybe dev could exclude that app by default, just like Gcam.

          I did some quick digging and found relevant issues here and here. The latter issue in the GrapheneOS issue tracker has naturally been closed as it's an issue in OsmAnd.