You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HashMap, HashSet and HashTable are currently all 32 bytes.
Would you consider supporting a lower maximum size? For many use cases, a size limit of ~4 billion items is sufficient, so using u32 for items, bucket_mask and growth_left would suffice. This would reduce the size of the types to 24 bytes.
This may not seem a significant gain, but when using a great number of HashMaps, with a large proportion of them empty and unallocated, the overhead adds up to a significant % of total memory usage.
This could be implemented either as a feature or generic.
If you'd be willing to accept a PR for this, I'd be happy to work one up.
The text was updated successfully, but these errors were encountered:
As a user, you can also add indirection like Option<Box<HashMap<...>>> so it's only a pointer-sized None when empty. That's more of a hassle to actually use, of course, but you could hide that in a wrapper for your specific use-cases.
HashMap
,HashSet
andHashTable
are currently all 32 bytes.Would you consider supporting a lower maximum size? For many use cases, a size limit of ~4 billion items is sufficient, so using
u32
foritems
,bucket_mask
andgrowth_left
would suffice. This would reduce the size of the types to 24 bytes.This may not seem a significant gain, but when using a great number of
HashMap
s, with a large proportion of them empty and unallocated, the overhead adds up to a significant % of total memory usage.This could be implemented either as a feature or generic.
If you'd be willing to accept a PR for this, I'd be happy to work one up.
The text was updated successfully, but these errors were encountered: