This function currently allocates memory extremely inefficiently. Here are some examples: * It allocates memory even if the requested length in the same type of buffer already allocated is less than what we already have allocated. * It doesn't have nsTArray-like exponential growth with a cap behavior, so in cases where it's called in a loop it ends up allocating/copying too much, and can end up having quadratic behavior. * For performance reasons, it may be worth considering keeping the fragment wide once it is allocated as wide instead of freeing it and reallocating it as narrow if SetTo() is called later with a narrow string.

Note that this is a super small part of the profiles currently. I'm keeping the bug open hoping that after we shave off enough of the cost from other places here, this starts to become a significant part of the cost in profiles...

Per comment 1, seems this doesn't need to be P1 for 57 release...

Seems P2-ish.

bug 1375910's micro benchmark can improve 10%+ by WIP.

Just modified the WIP a bit to ensure we don't keep too large string buffers alive. remote: View your change here: remote: https://hg.mozilla.org/try/rev/fa39c24cb00c7c0bc8ddcc298f7daafe80a1c6a5 remote: remote: Follow the progress of your build on Treeherder: remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fa39c24cb00c7c0bc8ddcc298f7daafe80a1c6a5 remote: recorded changegroup in replication log in 0.064s

Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a0cf29a08c3d nsTextFragment::SetTo() could be faster by allocating less often, p=makoto,smaug, r=makoto,smaug