4 ms·

> Why would you store the size and capacity as part of the buffer? To decrease the memory footprint of your small strings. It can see how some uses cases where

> Why would you store the size and capacity as part of the buffer? 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. I was just curious to know if that design decision was based on analysis of a real use case, or if it was due to a compatibility issue or something.

masklinn 8y ago
> 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.
- JeromeBonnet 8y ago
  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?
  - masklinn 8y ago
    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.
    - deleted 8y ago
      [deleted]
twic 8y ago
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.

masklinn 8y ago

> 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.

JeromeBonnet 8y ago
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?
- masklinn 8y ago
  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.
  - deleted 8y ago
    [deleted]

twic 8y ago

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.