3 ms·
It's kind of like the small string optimization you see in C++[1] where all the string metadata to account for heap pointer, size and capacity is union'ed with
by matthewaveryusa 7mo ago
It's kind of like the small string optimization you see in C++[1] where all the string metadata to account for heap pointer, size and capacity is union'ed with char*. Getting the stack allocation doesn't costs extra memory, but does cost a bit check. Not sure if slices in go use the same method. 32 bytes is a lot so maybe they fattened slice representations a bit to get a bit more bang for your buck?
[1] https://github.com/elliotgoodrich/SSO-23 https://github.com/elliotgoodrich/SSO-23
- AdieuToLogic 7mo ago> It's kind of like the small string optimization you see in C++ ... Agreed. These types of optimizations can yield significant benefits and are often employed in language standard libraries. For example, the Scala standard library employs an analogous optimization in their Set[0] collection type. 0 - https://github.com/scala/scala3/blob/88438e2c6e6204e12666067926d43ebfe91d3dfa/library/src/scala/collection/immutable/Set.scala#L168 https://github.com/scala/scala3/blob/88438e2c6e6204e12666067...