Andor has been complaining about how slow it is to load files locally with xhr, especially when Chrome and Safari are so fast. He's got a test case here: http://scotland.proximity.on.ca/asalga/tests/local_xhr/Local_XHR.zip Video of test running on Mac here: http://www.youtube.com/watch?v=mXQkUgIG5DE Talking to smaug on irc, he mentions: "Based on Shark profile the slowness happens in a code which, IIRC, bz changed some time ago." He also mentions that the test Andor is doing is strange in the way it uses .responseText all the time vs. progress events; however, that quirk notwithstanding, this needs to be a lot faster.
Ok, I think bz didn't touch this particular code after all. It is old code.
We're spending ~18% in ConvertBodyToText to assign string value (I think the string should just adopt the outbuffer). Unicode conversion takes ~17%. Not sure how to optimize that.
We also call GC quite a bit.
Created attachment 489831 [details] Local XHR timing test I'm running: OSX 10.5.8 2.2GHz Intel Core 2 Duo 2GB RAM Minefield 4.0b8pre
I found the performance get progressively worse as the file size increases. I attached a screenshot of some tests I ran last night (see above)
Andor, btw, may I ask why you're using responseText to check how much data has been downloaded? Why not use progress events? http://mozilla.pettay.fi/xhr_upload/xhr_file_upload_demo_with_speed.html is a rather simple test for progress events. But anyway, need to speed up our responseText handling during XHR load. A patch coming hopefully soon to reduce string overhead.
> uses .responseText all the time vs. progress events; "Don't Do That". See bug 552573 and bug 560077 (of which this seems to be a duplicate) for more information. Reducing the string overhead is still a good idea, but the fundamental problem is just that we have to redecode at all (bug 560077); it makes the load O(N^2) in the file size.
But isn't poking .responseText done in all browsers? So while that seems like a perf opportunity for the website, it still doesn't excuse us being that much slower, right? I think we should assume that other people are poking .responseText too and so it's worth optimizing that pattern as well.
> it still doesn't excuse us being that much slower, right? Yes, that's what bug 560077 is about. If you can make it so we know whether the XML parser has already set the "final" charset on the document, we can fix that bug... (Oh, and there's an interesting side issue: what happens when responseText is gotten mid-character. I wonder what webkit does in that situation....)
Depends on: 560077
Adding progress events did the trick. Local XHR performance is now fine. Thanks Olli.
You need to log in before you can comment on or make changes to this bug.