Post

This is a great example of why even small optimizations can matter at scale. Modern apps and systems can be affected by this kind of "death by a thousand cuts".

P-Y@p-y.wtf

I wrote a little blog engineering.block.xyz/blog/18mb-of... #Android #AndroidDev

engineering.block.xyz18Mb of HashMap overheadCutting 18 Mb from Android memory by replacing a HashMap with a FloatArray

Brian Swetland

@swetland.frotz.net

30 Apr

Also a great example of how writing code thoughtfully in the first place entirely avoids dumb shit like this. Why in the world would you ever implement this with a hastable in the first place?

Romain Guy

@romainguy.dev

I see waaaaay too much code reach for a hash map whenever any association is needed. It's often not the right data structure (and on top of that, the standard map, especially in Kotlin the linked hash map, is a bit wasteful in terms of memory and cache access)

30/4/26, 3:31 pm0 reposts0 likes

Brian Swetland

@swetland.frotz.net

30 Apr

I also immediately wondered "how many of these i->f maps are identical?"... because 24674 of them at 64 bytes a piece is 1.5MB and that's before whatever the heap overhead is for each of those arrays....

P-Y

@p-y.wtf

1 May

I need to write a script to scan that heap dump and see how many identical maps this has... But also strong hunch that none of this code is right anyway. I don't know if I actually want to know more about it though. Veni, vidi, vomit. A little tweak & off I go