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...
Priority: P1 → P2
bug 1375910's micro benchmark can improve 10%+ by WIP.
Created attachment 8940695 [details] [diff] [review] text_setto.diff 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
Attachment #8940695 - Flags: review?(m_kato)
Attachment #8940695 - Flags: review?(m_kato) → review+
Pushed by email@example.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
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.