3 ms·
When are small strings bad? Parallelism?
by mhh__ 2y ago
When are small strings bad? Parallelism?
- workingjubilee 2y agoThe "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc. You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.
- n_plus_1_acc 2y agoYou'll need to branch on most operations to check "am i small?". This may cause issues with the Branche predictor.
- kibwen 2y agoRust APIs use string slices (&str) extensively. With its current design, converting from a String to a &str is a no-op; if String instead did small string optimization, converting to &str wouldn't be free. Furthermore, thanks to the borrow checker, Rust code tends to avoid copying strings around, so the benefit of SSO is reduced. C++ does more string copying and didn't have a standard string_view for a long time, so considering the tradeoffs both languages made reasonable decisions.
- steveklabnik 2y agoJust wanted to say that I only got back to this thread now, but I agree with my sibling commentors. Here's a discussion about it from a few years back, with some links to the primary discussions: https://news.ycombinator.com/item?id=18372332 https://news.ycombinator.com/item?id=18372332
- CJefferson 2y agoIt adds a branch every time you access the string (to check if it is small or not), and can stop various optimisations. g++ used to have small string optimisation, but (eventually) removed it.