[libcxx-commits] [PATCH] D155486: Optimize basic_string's memory usage

Nikolas Klauser via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Aug 4 09:48:19 PDT 2023


philnik added inline comments.


================
Comment at: libcxx/include/string:2338
+                    : __ms - 1;
+    } else {
+        // The current string is inlined (SSO). In this case we do not want to
----------------
mvels wrote:
> philnik wrote:
> > Why do we want to change the growth specifically for the case when we go from short to long?
> This is where most of the waste comes from, and we can also argue that the most common use case isn't actually 'Growing' the string, i.e., the doubling is to keep amortized growth on continued growth.
> 
> I.e., a common pattern is:
> ```
> std::string s;
> s = SomeValue();
> ```
> 
> In the above case assigning a value to s is not really "growing" the string, the fact that the size changes from 0 to n is a consequence of string not having a notion of "unassigned" (which is generally good).
> 
> But if you consider the above code, and `SomeValue()` returns a string of say, length 24, then the above algorithm would simply say we "grow from 0 to 24" and applies max(24, __min_cap * 2) = 44 bytes as minimum allocation size, which is wasteful.
> 
> Assigning values once to empty strings is a very common occurrence in practice, and there is no good reason to apply amortized growth to cases where a string goes from SSO to non SSO, and not doing so (precise sizing) saves memory,
My question was more meant as "why don't we just change the growth rate for everything?". That would save us a branch here, and AFAIK there is nothing preventing us from going that route.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155486/new/

https://reviews.llvm.org/D155486



More information about the libcxx-commits mailing list