Closed Bug 1252947 Opened 10 years ago Closed 8 years ago

tresize regressions with e10s and Linux/WinXP

Categories

(Testing :: Talos, defect, P2)

Product:
Testing
Component:
Talos
Platform:
Unspecified
Windows XP
Type:
defect

Tracking

(e10s+)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: gw280, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

+++ This bug was initially created as a clone of Bug #1179732 +++ Followup for WinXP only. Dashboard here: https://treeherder.mozilla.org/perf.html#/e10s?filter=tresize
tracking-e10s: ? → +
Priority: -- → P2
ni? myself to get data with APZC turned off.
Flags: needinfo?(gwright)
Just so we're clear, this ~5% tresize regression does not block e10s rollout?
Flags: needinfo?(jgriffiths)
Looking at Gabor's try run with APZC off: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&originalRevision=a4929411c0aa&newProject=try&newRevision=850e39c8f668&framework=1&filter=tps&showOnlyImportant=0 It looks like TPS is a win in every case with just e10s and no-APZC. I think based on that we shouldn't block on this. That being said, we don't have WinXP results in that try run. I will get those.
Flags: needinfo?(gwright)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #2) > Just so we're clear, this ~5% tresize regression does not block e10s rollout? it' snot clear to me if it should block, I wanted to start with tracking it as the xp regression is sizable and troubling. We still have lots of users on XP who could really use the benefits of e10s. I think the real question is: should this regression block the rollout of APZ to winxp users.
Flags: needinfo?(jgriffiths)
Doh, I pushed a try run for tps not tresize. oops.
Blocks: all-aboard-apz
Keywords: perf
OS: Unspecified → Windows XP
Summary: ~5% winxp tresize regression when comparing e10s to non e10s on the same build → ~5% winxp tresize regression when comparing e10s to non e10s on the same build on Windows XP
(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #5) > (In reply to Mike Conley (:mconley) - Needinfo me! from comment #2) > > Just so we're clear, this ~5% tresize regression does not block e10s rollout? > > it' snot clear to me if it should block, I wanted to start with tracking it > as the xp regression is sizable and troubling. We still have lots of users > on XP who could really use the benefits of e10s. > > I think the real question is: should this regression block the rollout of > APZ to winxp users. I'm not sure how applicable tresize is to real-world use cases. It's true that resizing is important, but tresize in its current state simply resizes a very simple test page. I think where e10s could really win is with a more complex test page that requires significant work to relayout when resizing a window. This would be where the separate child process would make a difference, as opposed to simply adding IPC overhead. I filed bug 1244800 to consider adding a new tresize test with a more complex use case.
Assuming this is 5% with APZ on and that dislayport suppression is working correctly on windows (it should), then bug 1251937 might help.
Bug 1251937 won't help for any non-tiling platforms.
(In reply to George Wright (:gw280) (:gwright) from comment #6) > Doh, I pushed a try run for tps not tresize. oops. Is this bug actually about tps? Everything you linked to since 3 onwards has been relating to tps and not tresize. The e10s talos dashboard currently shows a 12% regression for tresize on windows xp pgo [1]. I triggered some tresize winxp jobs on various pushes to find out how much is attributable to APZ, will update once those are done running. If this bug is really about tps though please update the summary. [1] https://treeherder.mozilla.org/perf.html#/e10s?filter=tresize
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10) > (In reply to George Wright (:gw280) (:gwright) from comment #6) > > Doh, I pushed a try run for tps not tresize. oops. > > Is this bug actually about tps? Everything you linked to since 3 onwards has > been relating to tps and not tresize. The e10s talos dashboard currently > shows a 12% regression for tresize on windows xp pgo [1]. Yeah, I was working on both tps and this and got my thoughts mixed up. :(
Summary: ~5% winxp tresize regression when comparing e10s to non e10s on the same build on Windows XP → ~11-12% winxp tresize regression when comparing e10s to non e10s on the same build on Windows XP
Blocks e10s "UI smoothness" release criteria
Blocks: 1251547
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10) > I triggered some tresize winxp jobs on various pushes to find out how much > is attributable to APZ, will update once those are done running. If this bug > is really about tps though please update the summary. So APZ appears to be responsible for ~3.7% of the 11-12% regression. So there's still a significant non-APZ component to this. Of the ~3.7% over half seems to be from the event regions code which we are working to optimize in various other bugs.
Given the above this isn't an APZ blocker. Feel free to file a new bug for the APZ component.
No longer blocks: apz-desktop-blockers
Inbound doesn't appear to be reporting these tests regularly, but central has good data. 1) opt builds show bimodal results for non-e10s. e10s beats the upper values. 2) pgo builds also show bimodal results for non-e10s. e10s regresses by about 4-5%. I don't see a reason to block on this. https://treeherder.mozilla.org/perf.html#/graphs?series=%5Bmozilla-inbound,30a5e3956293e1bd45ccc18b090fe0430b73b049,0%5D&series=%5Bmozilla-inbound,38bd3469cede78e761940dfa73c9bca261ab20db,0%5D&series=%5Bmozilla-central,ff4ce004871790022f413b1abb21632e7c788f65,1%5D&series=%5Bmozilla-central,2c2a8f5bf693abaac9441bda475152c167bf24e0,1%5D&series=%5Bmozilla-central,75d3930fd34d3fed0e05e877bb14830aca67a00d,1%5D&series=%5Bmozilla-central,1e18b085f1eb48281356cc0b44ef2a3b4bec77aa,1%5D
Summary: ~11-12% winxp tresize regression when comparing e10s to non e10s on the same build on Windows XP → 4-5% tresize regression with e10s (Windows XP pgo)
The e10s Perfherder dashboard shows Linux has regressed about 9% and XP about 6%: https://treeherder.mozilla.org/perf.html#/e10s?filter=tresize
(In reply to Chris Peterson [:cpeterson] from comment #17) > The e10s Perfherder dashboard shows Linux has regressed about 9% and XP > about 6%: > > https://treeherder.mozilla.org/perf.html#/e10s?filter=tresize Orange background at the dashboard numbers mean the results are somewhat noisy or that the automated comparison is not fully reliable - and therefore a human should assess it visually by observing the graphs. If you click the Linux "graph" link, you'll see that non-e10s has improved while the e10s numbers didn't really change. As for XP, it looks to me as if the dashboard cannot "see" non-e10s data points except for few very recent ones, where the e10s appear, again, to be relatively solid (somewhat more noisy recently, but not really worse than before on average). Whether or not the fact that e10s "became worse" than non-e10s only because the latter improved should be considered an e10s regression or not - up to you.
Depends on: 1256649
I filed bug 1256649 on the e10s perf dashboard tresize data being broken. For now do your own comparisons in perfherder on inbound. For example: win xp pgo: 10.39 -> 10.53 linux64 pgo: 21.65 -> 23.56 OS X 10.10 opt: e10s talos isn't running here afaict
tresize measures the time it takes to open a new browser window. So for example, how much time it takes to display and paint a new window after the user hits control-n. Numbers range around 10-30 msecs.
(In reply to Jim Mathies [:jimm] from comment #21) > tresize measures the time it takes to open a new browser window. So for > example, how much time it takes to display and paint a new window after the > user hits control-n. > > Numbers range around 10-30 msecs. eh, sorry, incorrect description. tresize measures the time it takes to resize a browser window by about 10 pixels in width and height. New windows are measure by a different talos test.
(In reply to Jim Mathies [:jimm] from comment #20) > Dashboard numbers are back. Worst offender is Linux, with a 1-2 msec > regression. XP has .5 msec regression, osx has about a 1 msec regression, > and win8/10 improve by 1 msec. > > I'm completely comfortable with these numbers for rollout. Jeff, can you > sign off on this or would you like us to dig in further? Looks good to me
Flags: needinfo?(jgriffiths)
Jim, does Jeff's comment 23 mean we can resolve this tresize bug as WORKSFORME and consider the tresize release criteria as passing?
Flags: needinfo?(jmathies)
(In reply to Chris Peterson [:cpeterson] from comment #24) > Jim, does Jeff's comment 23 mean we can resolve this tresize bug as > WORKSFORME and consider the tresize release criteria as passing? I updated the wiki. Lets keep this open since there is a regression on linux that we're willing to take. Also, apz affects these numbers so depending on what we do with that, the tresize numbers might change.
Flags: needinfo?(jmathies)
Assignee: jmathies → nobody
See Also: → 1257869
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.