Closed Bug 813204 Opened 9 years ago Closed 9 years ago
Loading the economist is hellaslow
The spinner stays up for a really long time (if it even goes away at all) and there are multiple unresponsive script warnings. Also there's a lot of AndroidBridge::HandleGeckoMessage spew in the logcat which seems to be because of sending the Tab:HasTouchListener message over and over. dbaron also reported that loading two articles causes his device to completely die (the second page load apparently has some sort of banner/image/floating window that moves up onto the screen).
Can we try to separate network from other (parsing, layout and rendering)? Is this on wifi or mobile connections?
This is on wifi. I don't think much if any of the slowness comes from network here; it seems to be mostly scripts/rendering. I'm trying to get a profile of the page load to see what's going on.
Changing the UA do anything differently?
(In reply to Aaron Train [:aaronmt] from comment #3) > Changing the UA do anything differently? It seemed to help a bit but I still get the unresponsive script warnings.
(In reply to Kartikaya Gupta (:kats) from comment #4) > (In reply to Aaron Train [:aaronmt] from comment #3) > > Changing the UA do anything differently? > > It seemed to help a bit but I still get the unresponsive script warnings. That is controlled with a pref: http://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#407 Which is set to 20 seconds. There has to be something worth profiling in the JS.
I think it's just hellaslow on debug builds. The non-debug build that I used for profiling was definitely faster, and I don't hit the unresponsive script warnings there. There are a lot of JS-triggered sync reflows in the profile which explains the general lagginess. Seems to be mostly coming from the brightcove player on the page. http://people.mozilla.com/~bgirard/cleopatra/#report=3e6fa92f8b9c53e1a004374e3352bd39813ecd2d
This at least prevents us from sending bajillions of Tab:HasTouchListener events to java. Ideally the platform code wouldn't even send out all these events but I don't know if there is other code that relies on the existing behaviour.
Attachment #683669 - Flags: review?(wjohnston)
I can get the unresponsive script dialog on the Galaxy 551 (ARMv6, 384MiB) and got the stack in the profiler. I wasn't able to get a good profile of what the script was doing before it hit this point; the profiler can't get a dump from the device while the script is hogging the main thread. However based on the profiles I got previously I'm pretty sure it's just the content scripts running amok and triggering lots of sync reflows.
Attachment #683669 - Flags: review?(wjohnston) → review+
I don't know what else we can do to improve this site specifically; it seems like general memory usage reductions will help and the rest is evangelism so their scripts don't do stupid things. I also wasn't able to reproduce getting the subscription banner that dbaron and blassey said appears after a few page loads. They might have gotten rid of it, or maybe it's not offered to Canadian IP addresses or something. If anybody else can reproduce that please let me know. For now though I'm going to land this patch rather than let it rot. https://hg.mozilla.org/integration/mozilla-inbound/rev/d00a4624190f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.