<https://www.romainguy.dev/posts/2024/a-better-has...

# feed

[Youssef Shoaib [MOD]]

https://www.romainguy.dev/posts/2024/a-better-hashmap/

I always wondered if HashMap could be improved!

[ephemient]

if you have integer keys and you really need to minimize memory usage, androidx.collection already has SparseArrayCompat, which is just a non-framework copy of android.util.SparseArray. it has some similar downsides, such as not being able to satisfy the Map interface without conversion, and a few others (algorithmic complexity of O(log n) rather than O(1) for indexing, etc.)

[ephemient]

SimpleArrayMap is another point in the space of data structures with different trade-offs

[Anonymike]

Great stuff! A related, but most often used for caching mechanism (and a fantastic lesson in data structures) is ben manes' near optimal concurrent map, which he developed while at Google called Caffeine cache, because it is most commonly used for caching, but it has some fantastic uses and there's even some wrappers for kotlin to create suspending caches.

https://github.com/ben-manes/caffeine

This is incredibly powerful for Kotlin on the server / backend.

[Anonymike]

I'll definitely be checking out ScatterMap to compare with some other libraries we use or alongside primitave maps.

[ephemient]

I remember lots of java projects used to use trove or fastutil for their specialized collections too. I think kotlinc still has references to Trove

[Anonymike]

Great point and that wouldn't surprise me at all. They do help a lot in large cache and lookup scenarios for memory and lookup speed.

[Youssef Shoaib [MOD]]

I do also really like that, seemingly, this fixes some pitfalls with using Java's Map interface in Kotlin, including the presence of non-inline methods.

[Arjan van Wieringen]

It would be awesome if JB would implement fast datastructures for Compose Web and HTML