813204 - Loading the economist is hellaslow

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

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

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Can we try to separate network from other (parsing, layout and rendering)? Is this on wifi or mobile connections?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

[Aaron Train [:aaronmt]]

Changing the UA do anything differently?

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Don't send unnecessary HasTouchListener events

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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Stack to the unresponsive script dialog

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.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/d00a4624190f