Re:Proposed New Go GC: Transaction-Oriented Collector
by Jweb_Guru on Friday June 24, 2016 @02:12PM
(#11972082)
Additionally, in C++ strings of less than 23 (IIRC) bytes are not heap allocated (they reuse fields in the existing structure). Whether this is a good thing is a matter of opinion, of course.
Re:Proposed New Go GC: Transaction-Oriented Collector
by masklinn on Friday June 24, 2016 @03:56PM
(#11972929)
> Additionally, in C++ strings of less than 23 (IIRC) bytes are not heap allocated (they reuse fields in the existing structure).
Not quite. SSO is a lib-specific optimisation. LLVM's libc++ has a 22 characters SSO[0], recent MSVC and recent GNU libstdc++ have 15 characters SSO, Apache and older libstdc++ didn't have SSO at all (and used COW).
The SSO-23 POC/proposal does provide a 23-characters SSO for a 24 bytes string structure (such as LLVM's, MSVC 2013 and modern G++ strings are 32 bytes and SSO-23's scheme provides space for 31 characters in the same stack space).
[0] all capacities exclude the final NUL as it's required and unusable outside of C compatibility
You can use either a fixed size arena allocator, or one using alloca(you better know what you're doing) and still allocate those things on the stack.
In cases where you know the bounds of your input and runtime constraints you can get some really incredible performance boosts(multi-orders of mag) with those approaches.