[libcxx-commits] [PATCH] D102727: Use precise growth rather than amortized growth in std::string::resize/__resize_default_init.

[Evan Brown via Phabricator via libcxx-commits]

ezbr added a comment.

In D102727#2858165 <https://reviews.llvm.org/D102727#2858165>, @ldionne wrote:

> If this is only an experiment and we're not sure we want to keep it, I would much prefer that you enable it internally in your downstream fork and then upstream it alongside with the data you gathered if the experiment turns out to be positive. When we add options to libc++, people are free to start using them and they are a lot harder to remove. I'd be happy to make this the default in libc++ if it's shown to be an improvement and keeps us conforming.

Changed to update the default behavior instead of adding a compiler option. We've experimented internally and find that this is a desirable change (see updated change description).

> Regarding the change itself, let me make sure I understand. Basically, this patch calls `reserve(n)` automatically whenever someone calls `resize(n)`, so that we end up not growing the string exponentially in `append()` if we don't have enough capacity. Another way to achieve this would be to *not* perform `2 * __old_cap` in `__grow_by_and_replace()`, however this would also mean that a loop using `push_back()` repeatedly would have quadratic complexity (because we'd be growing by exactly 1 element each time), which is bad. Is that right, and is that why you're only adding this knob in `resize()`?

Your understanding is correct. `push_back()` also relies on `__grow_by()` and is required to have amortized constant complexity. Updated the change description to include this information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102727