elastic / go-freelru

GC-less, fast and generic LRU hashmap library for Go
Apache License 2.0
144 stars 9 forks source link

Memory overhead #31

Open academe-01 opened 3 months ago

academe-01 commented 3 months ago

Hello!

Could you please provide information on the memory overhead per stored item when using LRU in Go?

Additionally, I have a use case where the key is a [32]byte and the value is a pointer to a struct. Which of the following approaches would be faster:

1.  Using go-freelru to store the key and a pointer to the struct.
2.  Using go-freelru to store the key and an index (e.g., uint64) which references a separate map holding all values.

Thank you!

rockdaboot commented 3 months ago

Could you please provide information on the memory overhead per stored item when using LRU in Go?

The memory overhead of key and value is the size of the key and value types multiplied by the number of max number of elements (the number you set with the New functions).

Which of the following approaches would be faster:

In general: If you only need to read-access your values by key, store the struct in the LRU, and don't use a pointer. If the value structs exceed a certain size (128?), the Go compiler won't embed the value and use pointers anyways. If the value struct members need to be changed after storing the values in the LRU, use pointers.

When you say "index" into a "map", I am not sure what you are talking about. If the uint64 value is an index into an array: the LRU maintains an internal array of your values anyways. So if you are using the index just for lookups, store the struct itself in the LRU. If the uint64 value is the key for a Go map lookup, then yes, store it as value in the LRU.

Summary: This can be complex and there are lots of different use cases and corner cases. If in doubt, do your own benchmarks. Then you have a prove for whatever you decide for.