GrapheneOS – When an app is slow

(blog.wirelessmoves.com)

49 points | by speckx 2 hours ago

5 comments

  • hadi77ir 14 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?
  • negative_zero 1 hour ago
    Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
    • BlackRabbit1 19 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.

      • broodbucket 9 minutes ago
        Waze works perfectly fine for me
        • DuncanCoffee 2 minutes ago
          Anyone writing about apps compatibility should specify if it's with or without the play services
          • DaSHacka 0 minutes ago
            Can you even run Waze/GMaps without Play services?
      • ThePowerOfFuet 9 minutes ago
        I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
  • Groxx 44 minutes ago
    Huh. Yeah, it is noticeably faster on my 9a with that disabled. I wonder what they're doing differently...
  • pjmlp 1 hour ago
    Maybe the actual solution is to improve, replace the application.
    • izacus 1 hour ago
      Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
      • Groxx 42 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.
        • izacus 19 minutes ago
          That's trivially provable as false.
          • nvme0n1p1 15 minutes ago
            If so, I'd love to know which OEM you're thinking of who ships an Android distro more secure than GrapheneOS.
            • izacus 5 minutes ago
              Let's first start with y'all providing any proof that it was "benchmaxxing" that causes OEMs not to ship hardened allocators (and not - for example - breaking compatibility with users' software).

              And then we can move the goalposts to "more secure distro with GrapheneOS" which isn't part of the conversation until you dragged it out.

      • palata 10 minutes ago
        Maybe... legacy?
      • pjmlp 42 minutes ago
        Because they cut costs on hardware and not all ship MTE enabled ARMs.
    • mohamedkoubaa 1 hour ago
      There needs to be a wall of shame for apps that abuse hardware owned by users
      • yjftsjthsd-h 1 hour ago
        How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
        • pjmlp 41 minutes ago
          The AOSP memory allocator is seldom the one used by OEMs.
          • rpdillon 6 minutes ago
            Really? They're not using Scudo? The hardened_malloc used in GrapheneOS has a bunch of performance issues that were trade-offs against security. Every other major android distribution uses scudo as far as I know. Which OEMs are you thinking of?

            Edit: Did some research after writing this? It appears that Samsung may be still using jemalloc, albeit a newer version than the one from the Android 11 days.

        • perching_aix 53 minutes ago
          That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
  • perching_aix 1 hour 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?

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