XHR of local files slower than Chrome/Safari

NEW
Unassigned

Status

()

Core
DOM
7 years ago
7 years ago

People

(Reporter: humph, Unassigned)

Tracking

(Depends on: 1 bug, {perf})

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.

Comment 1

7 years ago
Ok, I think bz didn't touch this particular code after all.
It is old code.

Comment 2

7 years ago
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.

Comment 3

7 years ago
We also call GC quite a bit.

Comment 4

7 years ago
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

Comment 5

7 years ago
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)

Comment 6

7 years ago
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....)

Updated

7 years ago
Depends on: 611647

Updated

7 years ago
Depends on: 611664

Comment 10

7 years ago
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.