4 ms·
Unboxing is a huge optimisation though isn’t it? No need to allocate when inserting a new item into the queue (beyond the standard allocations which happen when
by joppy 5y ago
Unboxing is a huge optimisation though isn’t it? No need to allocate when inserting a new item into the queue (beyond the standard allocations which happen when growing a slice), fewer pointer indirections when reading the queue, easier garbage clean up at the end (a single deallocation of a slice).
I think (but am not sure) that the Go compiler can add some small primitive types and structs (precisely: those that fit in a machine word) to a []interface{} by storing them inline, removing the need for an allocation. So perhaps you will only see major speed increases when using larger structs.
- foldr 5y agoWith larger structs it’s a double-edged sword. Unboxing them also means that the deque implementation has to copy a lot more memory when extending the underlying slices. Unboxing is typically an optimization, for sure. I guess I disagree that it’s a ‘huge’ one except maybe in the case of arrays/slices (where you can do it anyway in Go without generics).
- omegabravo 5y agoThat's an incredible memory you have. Word sized values can be inline, but they still have the type overhead. I only know this since I just checked