I don't think it decreases the overall memory use of small strings - it just moves that use from the string struct to the character buffer. Bear in mind that in this design, the character buffer is never shared between multiple string structs; they each own their own separate buffer. If you want multiple references to the same string, you would use several pointers to a string struct, rather than having several string structs sharing the same buffer.

If you're coming from a GC'd language like Java, Ruby, etc, then there's a bit of a mindset shift around strings.

> To decrease the memory footprint of your small strings. It can see how some uses cases where a large proportion of strings are very small would benefit from it.

If you do that you have to spill your SSO to the heap way earlier, rapidstring would have 15 bytes SSO instead of the current 31, and std::string would be limited to 7 compared to the current 23~31.

It is a trade off. I see the length limit is 23 for SSO-23, but it could have been arbitrarily larger. What is the basis for the determination of those magic length limit targets?

The size of the pre-existing non-SSO string. SSO-23 is predicated on a stack layout of (pointer, capacity, size) (as in Clang). That's why SSO-23 applied to the pre-existing MSVC or GCC std::string yields 31 on-stack bytes, they have a stack size of 32 bytes.