700248 - Consider decoding script files into PRUnichars incrementally

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Henri Sivonen (:hsivonen)]

nsScriptLoader uses nsIStreamLoader to request the whole script file as a contiguous byte buffer from Necko. This has to mean that Necko does some extra copying. Also, the conversion to UTF-16 can happen synchronously for large amounts of input.

Consider using the lower-level network stream APIs and incrementally converting the input to UTF-16 on each OnDataAvailable call.

Possible disadvantages include the UTF-16 data being larger than the byte data and more copying possibly happening on the UTF-16 side.

(Perhaps instead of buffering up the UTF-16 data, the data should be pushed piecemeal to the JS parser immediately. Is that supported?)

Comment 1

[Boris Zbarsky [:bzbarsky]]

The JS engine needs the UTF-16 data in a single chunk.

For the rest, you're basically proposing that we use nsIUnicharStreamLoader, right?  Now that this hands in an nsAString, not an actual nsIUnicharInputStream, it seems like it's exactly what you want.

And yes, that will involve some realloc activity for the UTF-16 buffer...

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky (:bz) from comment #1)
> The JS engine needs the UTF-16 data in a single chunk.

How deeply is that set in stone? That is, does the code organization of the JS parser preclude opening an incremental parsing API where the app could push PRUnichar buffers to the JS engine and the JS engine would parse each buffer incrementally (like the HTML and XML parsers do)? Obviously, the whole point would be that the JS parser could actually consume buffers incrementally instead of just collecting everything into a big buffer first internally.

> For the rest, you're basically proposing that we use nsIUnicharStreamLoader,
> right?

Probably. I didn't know such a thing existed.

> And yes, that will involve some realloc activity for the UTF-16 buffer...

Yeah, this is a "consider" bug. It's unclear if changes are worthwhile.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> How deeply is that set in stone?

I'd check with the JSeng folks.  I seem to recall they had some sort of streaming capability that the shell used and nuked it for better parsing performance.  But I could be wrong.

Comment 4

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.