2043732 - JS_NewStringCopyUTF8N sometimes does two passes over the buffer - makes mozilla::IOUtils::JsBuffer::IntoString slow

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P1)

Description

[Markus Stange [:mstange]]

Mayank shared this profile from Firefox startup with a 300MB session JSON file: https://share.firefox.dev/4dpVWVM

We can see IOUtils::JsBuffer::IntoString doing two passes over the input.

Comment 1

[Markus Stange [:mstange]]

Attachment: Bug 2043732 - Use encoding_rs for UTF-8 to UTF-16 string inflation. r=jandem

InflateUTF8StringHelper used a hand-rolled byte-by-byte decoder that
walked the input twice: a counting pass to compute the output length and
a copy pass to emit the chars. Route the char16_t case through a new
InflateUTF8ToNewTwoByteCharsZ helper that allocates srclen + 1 char16_t
and runs a single SIMD pass via encoding_rs
(mozilla::ConvertUtf8toUtf16{,WithoutReplacement}). On invalid UTF-8 in
Throw mode, fall back to the slow validator just to preserve the precise
byte-offset error report. The Latin1 path is unchanged.

This speeds up IOUtils::JsBuffer::IntoString by around 2.5x, so it should
speed up session restore.

Before: https://share.firefox.dev/3POjZVq
After: https://share.firefox.dev/4o5j5AE

Comment 2

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=51986

Comment 3

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=53676

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e3fb3fa6d3df
https://hg.mozilla.org/integration/autoland/rev/1da86eca6139
Use encoding_rs for UTF-8 to UTF-16 string inflation. r=jandem

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/1da86eca6139

Comment 6

[Mayank Bansal]

can the same technique be used in StringBuilder::append (Utf8Unit*) ?

Comment 7

[Markus Stange [:mstange]]

Not sure - do you have a profile that spends time in it?

Comment 8

[Mayank Bansal]

(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.