(In reply to Markus Stange [:mstange] from comment #7) > Not sure - do you have a profile that spends time in it? I do not. Just for curiosity, I put your patch in chatgpt, and asked it where else can similar pattern be used. This was the response: > The patch fixes the standalone TwoByteCharsZ path, but StringBuilder::append still does exactly what the old code did: it counts UTF-16 length first, grows the buffer, and then inflates again. That is still a full double walk over the remaining UTF-8 input. Reworking that call site to use the same “upper-bound allocate, convert once, maybe shrink” pattern is probably the highest-ROI follow-up because it sits on a general-purpose append path, not a niche API.
Bug 2043732 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Markus Stange [:mstange] from comment #7) > Not sure - do you have a profile that spends time in it? I do not. Just for curiosity, I put your patch in chatgpt, and asked it where else can similar pattern be used. This was the response: > StringBuilder::append(Utf8Unit*, size_t) is now the obvious next hotspot > The patch fixes the standalone TwoByteCharsZ path, but StringBuilder::append still does exactly what the old code did: it counts UTF-16 length first, grows the buffer, and then inflates again. That is still a full double walk over the remaining UTF-8 input. Reworking that call site to use the same “upper-bound allocate, convert once, maybe shrink” pattern is probably the highest-ROI follow-up because it sits on a general-purpose append path, not a niche API.