Closed
Bug 1075644
Opened 10 years ago
Closed 3 years ago
Follow-up to initializing Gecko thread sooner
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: jchen, Unassigned)
References
Details
Attachments
(3 files, 2 obsolete files)
2.89 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
7.80 KB,
patch
|
snorp
:
review+
bnicholson
:
review+
|
Details | Diff | Splinter Review |
2.81 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
We want to reduce the Nexus S throbber start regression after bug 888482 landed.
Reporter | ||
Comment 1•10 years ago
|
||
I think these are safe to move around without risking regression. They are part of startup anyways, and moving them to after Gecko start can let us parallelize better.
Attachment #8498339 -
Flags: review?(mark.finkle)
Reporter | ||
Comment 2•10 years ago
|
||
We should reduce Gecko thread priority at the very start. ThreadUtils.reduceGeckoPriority already takes care of checking for single-core devices.
Attachment #8498345 -
Flags: review?(snorp)
Comment 3•10 years ago
|
||
Comment on attachment 8498339 [details] [diff] [review] Move more things to after Gecko start (v1) Worth a try
Attachment #8498339 -
Flags: review?(mark.finkle) → review+
Comment 4•10 years ago
|
||
Comment on attachment 8498345 [details] [diff] [review] Reduce Gecko thread priority at very start (v1) Review of attachment 8498345 [details] [diff] [review]: ----------------------------------------------------------------- Drive-by comments: * The priority gets reset here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/TopSitesPanel.java#402. That is, TopSitesPanel is responsible for both lowering and resetting the priority. Moving part of that to GeckoThread makes us lose that parity. * There's no guarantee TopSitesPanel gets shown during startup -- consider session restore, for example. That means it will always take 10 seconds (the timeout) to reset the priority in these cases. * A related point: since there's little UI shown for session restore startups, do we even want to lower the Gecko priority?
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Brian Nicholson (:bnicholson) from comment #4) > Comment on attachment 8498345 [details] [diff] [review] > Reduce Gecko thread priority at very start (v1) > > Review of attachment 8498345 [details] [diff] [review]: > ----------------------------------------------------------------- > > Drive-by comments: > * The priority gets reset here: > http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/ > TopSitesPanel.java#402. That is, TopSitesPanel is responsible for both > lowering and resetting the priority. Moving part of that to GeckoThread > makes us lose that parity. I don't think we need parity within TopSitesPanel here. It's easy enough to see who's calling reduceGeckoPriority/resetGeckoPriority. > * There's no guarantee TopSitesPanel gets shown during startup -- consider > session restore, for example. That means it will always take 10 seconds (the > timeout) to reset the priority in these cases. I see. How about we also reset priority at other places (e.g. at throbber start)? > * A related point: since there's little UI shown for session restore > startups, do we even want to lower the Gecko priority? We still load a lot of UI (inflating views, constructing classes, etc.) despite not showing it, so we do want to lower the Gecko priority.
Comment 6•10 years ago
|
||
Comment on attachment 8498345 [details] [diff] [review] Reduce Gecko thread priority at very start (v1) Review of attachment 8498345 [details] [diff] [review]: ----------------------------------------------------------------- I agree with :bnicholson's points, we should make sure we're upping the priority in the right spots.
Attachment #8498345 -
Flags: review?(snorp)
Reporter | ||
Comment 7•10 years ago
|
||
What about we separately reduce Gecko priority during UI loading? This way thumbnail loading is not affected -- when loading UI, we reduce priority, then reset it; then when loading thumbnail later, we reduce priority again, then reset it again.
Attachment #8498345 -
Attachment is obsolete: true
Attachment #8498998 -
Flags: review?(snorp)
Attachment #8498998 -
Flags: review?(bnicholson)
Reporter | ||
Comment 8•10 years ago
|
||
Oops, the last patch didn't include the reduceGeckoPriority change in TopSitesPanel.java.
Attachment #8498998 -
Attachment is obsolete: true
Attachment #8498998 -
Flags: review?(snorp)
Attachment #8498998 -
Flags: review?(bnicholson)
Attachment #8499003 -
Flags: review?(snorp)
Attachment #8499003 -
Flags: review?(bnicholson)
Comment 9•10 years ago
|
||
Comment on attachment 8499003 [details] [diff] [review] Reduce Gecko thread priority at very start (v3) Review of attachment 8499003 [details] [diff] [review]: ----------------------------------------------------------------- I think this looks OK. Is this a speculative fix, or have you already confirmed that this helps the throbber times?
Attachment #8499003 -
Flags: review?(bnicholson) → review+
Reporter | ||
Comment 10•10 years ago
|
||
(In reply to Brian Nicholson (:bnicholson) from comment #9) > Comment on attachment 8499003 [details] [diff] [review] > Reduce Gecko thread priority at very start (v3) > > Review of attachment 8499003 [details] [diff] [review]: > ----------------------------------------------------------------- > > I think this looks OK. Is this a speculative fix, or have you already > confirmed that this helps the throbber times? Speculative mostly, since autophone only monitors things that have landed.
Updated•10 years ago
|
Attachment #8499003 -
Flags: review?(snorp) → review+
Reporter | ||
Comment 11•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/f5db0dae1434 https://hg.mozilla.org/integration/fx-team/rev/4fee6e1f1ad2
Comment 12•10 years ago
|
||
Backed out for likely being the cause of various ContextMenu failures on Android 2.3. https://hg.mozilla.org/integration/fx-team/rev/8f1758ce53f0 https://treeherder.mozilla.org/ui/logviewer.html#?job_id=830587&repo=fx-team https://treeherder.mozilla.org/ui/logviewer.html#?job_id=830188&repo=fx-team
Comment 13•10 years ago
|
||
I suspect that these intermittent crashes were yours as well: https://treeherder.mozilla.org/ui/logviewer.html#?job_id=831255&repo=fx-team
Comment 14•10 years ago
|
||
Looks like this regressed autophone for Nexus S devices. Other devices had a small improvement. I wonder if it's the GeckoThread priority change? Could we check for single processor devices and skip the thread priority change? Is it worth it?
Comment 15•10 years ago
|
||
mfinkle, it regressed total throbber time but that was partly due to the huge improvement in throbber start time with an unchanged throbber stop time.
Comment 16•10 years ago
|
||
(In reply to Bob Clary [:bc:] from comment #15) > mfinkle, it regressed total throbber time but that was partly due to the > huge improvement in throbber start time with an unchanged throbber stop time. Oh damn, Bob, you're right! Ignore me.
Reporter | ||
Comment 17•10 years ago
|
||
These tests were failing because they assume the test page is loaded when the title changes. However, a page can still be loading when that happens. This patch changes them to wait for first paint.
Attachment #8505640 -
Flags: review?(mark.finkle)
Comment 18•10 years ago
|
||
Comment on attachment 8505640 [details] [diff] [review] Wait for page to fully load in context menu tests (v1) Seems sane to me
Attachment #8505640 -
Flags: review?(mark.finkle) → review+
Reporter | ||
Comment 19•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/47264e561dce https://hg.mozilla.org/integration/fx-team/rev/ca0dfff936c2 https://hg.mozilla.org/integration/fx-team/rev/c44f001ea6c1
Backed out for Android build bustage: https://hg.mozilla.org/integration/fx-team/rev/c8a9a49c5c10 https://treeherder.mozilla.org/ui/logviewer.html#?job_id=933799&repo=fx-team
Reporter | ||
Comment 21•10 years ago
|
||
Rebased push, https://hg.mozilla.org/integration/fx-team/rev/aa6ed82c6aa4 https://hg.mozilla.org/integration/fx-team/rev/47755f2acbc4 https://hg.mozilla.org/integration/fx-team/rev/f6de43db6fcf
https://hg.mozilla.org/mozilla-central/rev/aa6ed82c6aa4 https://hg.mozilla.org/mozilla-central/rev/47755f2acbc4 https://hg.mozilla.org/mozilla-central/rev/f6de43db6fcf
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Blocks: 1085627
Comment 23•10 years ago
|
||
Backed out for being the likely cause of bug 1085627. https://hg.mozilla.org/integration/fx-team/rev/f48ccb17a9e1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 36 → ---
Comment 24•10 years ago
|
||
Merge of backout: https://hg.mozilla.org/mozilla-central/rev/f48ccb17a9e1
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Comment 25•10 years ago
|
||
*sigh*
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 36 → ---
Reporter | ||
Updated•5 years ago
|
Assignee: nchen → nobody
Comment 27•3 years ago
|
||
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 3 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•