You'll probably be a lot better off a) preallocating the elements so your memory is nicely contiguous, b) tracking indices and not pointers. If I wanted to pay 24b overhead per item I'd use an `interface{}`. :)
Which pointer are you wanting to replace, there are a few and I can’t work out which would be best replaced with an int :) (not the author, and not a go developer, just reading through the code and couldn’t work out which you were talking about :) )
Nope, they don't. They just need to keep a list of free indices when the cache is not full. Upon eviction you reuse the deleted element's index.
This way, you store about O(capacity)*32bits for index in the worst case and save 32bits on left, right and the map pointers so your worst case space complexity is down by O(capacity).
I still expect that the saving from cache friendliness with preallocation will be the most significant.
Very thoughtful optimization. I'm usually guilty of just caring about Big O, usually just the time complexity.
If you parameterize on the type of capacity you can save even more. (But yes, same complexity - only in rare cases will you manage to store n values without O(n) memory. :) )
13 comments
[ 3.4 ms ] story [ 34.2 ms ] threadhttps://go.googlesource.com/proposal/+/refs/heads/master/des...
You'll probably be a lot better off a) preallocating the elements so your memory is nicely contiguous, b) tracking indices and not pointers. If I wanted to pay 24b overhead per item I'd use an `interface{}`. :)
Similar for what you want to preallocate.
Nope, they don't. They just need to keep a list of free indices when the cache is not full. Upon eviction you reuse the deleted element's index.
This way, you store about O(capacity)*32bits for index in the worst case and save 32bits on left, right and the map pointers so your worst case space complexity is down by O(capacity).
I still expect that the saving from cache friendliness with preallocation will be the most significant.
Very thoughtful optimization. I'm usually guilty of just caring about Big O, usually just the time complexity.
In Go, types without pointers also make the GC's life easier. https://go.dev/src/runtime/mheap.go#L525