Closed Bug 829100 Opened 11 years ago Closed 11 years ago

Lots of complaints of worse performance on Firefox 18 (vs 17) on play store

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
18 Branch
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox18+ wontfix, firefox19+ wontfix, firefox20+ wontfix, firefox21-)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox18 + wontfix
firefox19 + wontfix
firefox20 + wontfix
firefox21 - ---

People

(Reporter: joe, Assigned: cpeterson)

References

Details

(Keywords: regression)

Attachments

(1 file)

HTC Desire HD (Logs)
18.87 KB, application/zip
Details 
Looking at the play store feedback, there seems to be a feeling that Firefox 18 is slower, more resource intensive, slower to start up, etc than 17 was. It'd be nice if we could at least do a comparison to see whether this was the case, and if so, what happened to make it worse.
Tyler, anything from SUMO that can help shed some light on these complaints?
Flags: needinfo?(tdowner)
Brad, I haven't been able to get specifics yet (our Input database is borked ATM so I'm having to rely on manual reading of input). I did see the slowness complaints though.
Flags: needinfo?(tdowner)
The new JS engine may be consuming more resources?
(Devs can respond to reviews now; feel free to ask for info directly).
Progressive drawing isn't in 18 which was my first guess.
We'll track for FF18, although there isn't any actionable information in this bug at this point. We should try to compare the volume of slowness complaints in 17 vs 18, and those devices most impacted (if there is a correlation).
Tyler, can you close this as invalid based on the google play summary you sent out yesterday?
Flags: needinfo?(tdowner)
I'm still digging, hopefully by the end of this week I can tell if it's invalid or not. THere are more slowness reports than 17, but I can't find a correlation or even a lead.
Flags: needinfo?(tdowner)
Ben Hearsum said a friend hit this on a Desire HD. I asked if the friend could get a logcat or profile of the slowness.
I'll take a look at the upgrade process and aftermath on my Nexus One (semi-equivalent)
Any leads Tyler/Kevin/Aaron? Trying to determine whether this is something we need to track moving forward.
Was thinking about bug 835356 today; unconfirmed what other branches are affected there. Other than that, nothing from my testing. I dont know if Kevin collected logs from the Desire HD.
I picked up QA's Desire HD from cpeterson last Friday near the end of day. I've yet to have a chance to go into detail with the device but it is on my list.
Yeah; we talked in our mobile standup about this and we don't have enough leads to make further progress here. It's too late in the cycle for speculation.
Depends on: 838375
I tried to get a profile from my friend's device last week, but failed because it seems that the Gecko profiler doesn't work on Windows. I'm going to try again the next time I have the device in my hands (by the end of the month, hopefully).
(In reply to Ben Hearsum [:bhearsum] from comment #15)
> I tried to get a profile from my friend's device last week, but failed
> because it seems that the Gecko profiler doesn't work on Windows. I'm going
> to try again the next time I have the device in my hands (by the end of the
> month, hopefully).

Would your friend accept a replacement device by any chance?
(In reply to Alex Keybl [:akeybl] from comment #16)
> (In reply to Ben Hearsum [:bhearsum] from comment #15)
> > I tried to get a profile from my friend's device last week, but failed
> > because it seems that the Gecko profiler doesn't work on Windows. I'm going
> > to try again the next time I have the device in my hands (by the end of the
> > month, hopefully).
> 
> Would your friend accept a replacement device by any chance?

I'll ask about this.
(In reply to Ben Hearsum [:bhearsum] from comment #17)
> (In reply to Alex Keybl [:akeybl] from comment #16)
> > (In reply to Ben Hearsum [:bhearsum] from comment #15)
> > > I tried to get a profile from my friend's device last week, but failed
> > > because it seems that the Gecko profiler doesn't work on Windows. I'm going
> > > to try again the next time I have the device in my hands (by the end of the
> > > month, hopefully).
> > 
> > Would your friend accept a replacement device by any chance?
> 
> I'll ask about this.

He's open to this but wants to know what the replacement would be before agreeing to it. He's on Telus Mobility, if that makes a difference.
(In reply to Ben Hearsum [:bhearsum] from comment #18)
> (In reply to Ben Hearsum [:bhearsum] from comment #17)
> > (In reply to Alex Keybl [:akeybl] from comment #16)
> > > (In reply to Ben Hearsum [:bhearsum] from comment #15)
> > > > I tried to get a profile from my friend's device last week, but failed
> > > > because it seems that the Gecko profiler doesn't work on Windows. I'm going
> > > > to try again the next time I have the device in my hands (by the end of the
> > > > month, hopefully).
> > > 
> > > Would your friend accept a replacement device by any chance?
> > 
> > I'll ask about this.
> 
> He's open to this but wants to know what the replacement would be before
> agreeing to it. He's on Telus Mobility, if that makes a difference.

ping?
(In reply to Ben Hearsum [:bhearsum] from comment #19)
> ping?

Will check with mobile QA, since it'll likely be coming from them.
(In reply to Alex Keybl [:akeybl] from comment #20)
> (In reply to Ben Hearsum [:bhearsum] from comment #19)
> > ping?
> 
> Will check with mobile QA, since it'll likely be coming from them.

We can swap him with a brand new, unopened Galaxy Nexus.   let me know if that works.

http://www.gsmarena.com/samsung_galaxy_nexus_i9250-4219.php
(In reply to Tony Chung [:tchung] from comment #21)
> (In reply to Alex Keybl [:akeybl] from comment #20)
> > (In reply to Ben Hearsum [:bhearsum] from comment #19)
> > > ping?
> > 
> > Will check with mobile QA, since it'll likely be coming from them.
> 
> We can swap him with a brand new, unopened Galaxy Nexus.   let me know if
> that works.
> 
> http://www.gsmarena.com/samsung_galaxy_nexus_i9250-4219.php

He said this sounds great. Can we get it shipped to the Toronto office? He'll be in town two weeks today and I can do the switch then, and also have him show Aaron the behaviour first hand.
(In reply to Ben Hearsum [:bhearsum] from comment #22)
> (In reply to Tony Chung [:tchung] from comment #21)
> > (In reply to Alex Keybl [:akeybl] from comment #20)
> > > (In reply to Ben Hearsum [:bhearsum] from comment #19)
> > > > ping?
> > > 
> > > Will check with mobile QA, since it'll likely be coming from them.
> > 
> > We can swap him with a brand new, unopened Galaxy Nexus.   let me know if
> > that works.
> > 
> > http://www.gsmarena.com/samsung_galaxy_nexus_i9250-4219.php
> 
> He said this sounds great. Can we get it shipped to the Toronto office?
> He'll be in town two weeks today and I can do the switch then, and also have
> him show Aaron the behaviour first hand.

okay, i'll get a service now request on file.  Ben, i'll address the item to you at TO office.
Galaxy Nexus is ready in Toronto office - reserved for Ben and will hand over when his friend is in office.
(In reply to Jonathan Lin [:jlin] from comment #24)
> Galaxy Nexus is ready in Toronto office - reserved for Ben and will hand
> over when his friend is in office.

I'm expecting this to happen on Tuesday.
Aaron, I'm assuming that when Ben's friend brings in the phone tomorrow you'll be investigating?
QA Contact: aaron.train
Marc now has the Galaxy Nexus and his old phone (HTC Desire HD) is in Aaron's hands.
Attached file HTC Desire HD (Logs) — 
HTC Desire HD, Android 2.3.5, Sense 3.0, 3.13.661.4)

Findings so far, Firefox 18.0:

- Application is Not Responding (ANR)

* Device is frequently hitting bug 706500 (GeckoLayerClient.compositionPauseRequested(GeckoLayerClient.java:610)

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x400275d8 self=0xd050
  | sysTid=2764 nice=0 sched=0/0 cgrp=default handle=-1345002112
  | schedstat=( 49421111959 50306579770 44050 )
  at java.lang.Object.wait(Native Method)
  - waiting on <0x40027670> (a java.lang.VMThread)
  at java.lang.Thread.parkFor(Thread.java:1443)
  at java.lang.LangAccessImpl.parkFor(LangAccessImpl.java:48)
  at sun.misc.Unsafe.park(Unsafe.java:337)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:813)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:973)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1282)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
  at org.mozilla.gecko.GeckoAppShell.geckoEventSync(GeckoAppShell.java:629)
  at org.mozilla.gecko.GeckoAppShell.sendEventToGeckoSync(GeckoAppShell.java:594)
  at org.mozilla.gecko.gfx.GeckoLayerClient.compositionPauseRequested(GeckoLayerClient.java:610)


Also accessing different browser activities like the awesome-screen yield slow-down and eventually abort

02-26 14:37:58.717 D/GeckoAppShell( 3403): Gecko event sync taking too long: 4015ms
02-26 14:37:58.737 W/GeckoAppShell( 3403): Gecko event sync took too long, aborting!

2-26 14:37:58.737 W/GeckoAppShell( 3403): java.lang.Exception
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.GeckoAppShell.geckoEventSync(GeckoAppShell.java:402)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.GeckoAppShell.sendEventToGeckoSync(GeckoAppShell.java:337)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.gfx.GeckoLayerClient.compositionPauseRequested(GeckoLayerClient.java:603)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.gfx.LayerView.onDestroyed(LayerView.java:397)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.gfx.LayerView.access$400(LayerView.java:44)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at org.mozilla.gecko.gfx.LayerView$SurfaceListener.surfaceDestroyed(LayerView.java:439)
02-26 14:37:58.737 W/GeckoAppShell( 3403): 	at android.view.SurfaceView.reportSurfaceDestroyed(SurfaceView.java:600)

- Site load times

Loading http://www.wsj.com takes about three minutes on this device, see log; nothing stands out in the logs. Plenty of GC_EXTERNAL_ALLOC messages and DeviceStorageMonitorService messages

02-26 14:18:28.885 I/GeckoApp( 3126): Got a document start
02-26 14:21:30.332 I/GeckoApp( 3126): Got a document stop

02-26 14:18:46.983 V/DeviceStorageMonitorService( 1357): freeMemory=851222528
02-26 14:18:46.983 D/DeviceStorageMonitorService( 1357): OoO SMS Memory available. SMS_AVAILABLE_THRESHOLD == 524288
02-26 14:18:46.993 I/DeviceStorageMonitorService( 1357): Posting Message again

Firefox 20

Large improvement; http://www.wsj.com

02-26 14:33:29.074 I/GeckoToolbar( 3403): zerdatime 2338463 - Throbber start
02-26 14:33:18.774 I/GeckoToolbar( 3403): zerdatime 2328162 - Throbber stop
See Also: → 706500
Chris - now that QA has reproduced very poor performance on this phone, can you take a look?
Assignee: nobody → cpeterson
kats, according to AaronMT's logs, it looks like the UI thread is deadlocked at [1] waiting for a CompositorResumeEvent during surface destruction. But AFAICT createCompositorResumeEvent() is only called on the UI thread. How can the UI thread send itself a compositor resume event if it is blocked in surfaceDestroyed()?

[1] https://hg.mozilla.org/releases/mozilla-release/annotate/df50c7f50a16/mobile/android/base/gfx/GeckoLayerClient.java#l605
(In reply to Chris Peterson (:cpeterson) from comment #30)
> kats, according to AaronMT's logs, it looks like the UI thread is deadlocked
> at [1] waiting for a CompositorResumeEvent during surface destruction.

I'm not sure what you mean here. At [1] the UI thread is blocked on gecko processing the compositor pause event. The only thing it's waiting for is for gecko to respond to the event-sync message, which it should be able to do.

I'm trying to figure out what I think is the same bug over in bug 846774.
We can't take the fix in bug 846774 to beta because of risk involved in uplifting bug 844275 so this is going to have to be wontfixed for FF20.
status-firefox20: --- → wontfix
tracking-firefox21: --- → ?
Aaron, if you still have the device, can you test a build with bug 846774 fixed to see if you can reproduce the issues you mention in comment 28 with the gecko event sync?
Flags: needinfo?(aaron.train)
I still have the device, latest Nightly (03.12) feels snappier, and I'm not seeing the prior areas of contention. Provided I was seeing these on mozilla-release 18 as noted above. Hard to say wether bug 846774 has any affect. In any case, newer builds 20+ are better on this device.
Flags: needinfo?(aaron.train)
Duping to bug 846774. Will ride the trains.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
I'd rather leave this as FIXED rather than DUPLICATE just because I think there were probably other factors that went into fixing "general performance malaise" than my one patch. Leaving the dependency on bug 846774 though.
Resolution: DUPLICATE → FIXED
Not tracking this at this point as bug 846774 which has a potential fix for the issue here is already tracked & there is no WIP here .
tracking-firefox21: ? → -
tracking-fennec: ? → ---
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: