XHR of local files slower than Chrome/Safari

NEW
Unassigned

Status

()

P5
normal
8 years ago
5 months 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

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

Comment 4

8 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

8 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)
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....)

Comment 10

8 years ago
Adding progress events did the trick. Local XHR performance is now fine.
Thanks Olli.
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.