887015 - Huge amounts of CPU time spent in memcpy when using XMLHttpRequest.responseText

Status: NEW

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

Description

[Katelyn Gadd (:kael)]

When using XMLHttpRequest to stream large files, .responseText accesses seem to produce tons and tons of reallocations and memcpy operations. In my profiles the memcpy traffic alone accounts for 10-13% of CPU time according to the SPS profile.

The reallocations also create a lot of GC pressure and pauses.

Things that would help here:

Avoid reallocating the responseText string's buffer repeatedly (this has other benefits, in particular reducing the consequences of the responseText leak)

Being able to stream an arraybuffer response (last time I checked this doesn't work?)

Being able to request a string or array buffer representing a subset of the response (instead of getting back a 40MB string representing an entire 40MB file)

Being able to adjust the chunk size the browser uses when notifying you about updates via onreadystatechange.


For reference, this is the library I am using to stream TAR files via XHR:
https://github.com/kevingadd/JSIL/blob/tar/Libraries/multifile.js

Let me know if you need a full test case to test against and I can upload one (it's big, though)

Comment 1

[Katelyn Gadd (:kael)]

There's a test case up that demonstrates the problem:
http://hildr.luminance.org/bugs/3/Lumberjack/Lumberjack.html?disableSound

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Talk to ack -- he has some tar+IndexedDB stuff.  Also, yeah, XHR will realloc, though so will arraybuffer.  responseText is doubly awful though, because it's ucs2; why use responseText and not an arraybuffer? (you can do chunked arraybuffer)

In the future we also plan to honor content-length and preallocate a buffer if possible.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Avoid reallocating the responseText string's buffer repeatedly

Not really doable if JS asks for the .responseText repeatedly, because it's sharing the underlying buffer, which therefore cannot be modified in-place....

> Being able to stream an arraybuffer response (last time I checked this doesn't work?)

chunked-arraybuffer should work, though it's Gecko-only last I checked.

> Being able to request a string or array buffer representing a subset of the response

Does using HTTP Range headers not work?  Note that this may not play nice with gzip encoding, though.

> In the future we also plan to honor content-length and preallocate a buffer if possible.

That won't help if the web page polls .responseText on progress, unless the JS GC is very expeditious about dropping those strings; see above.