Confirm e10s causes a 40–50% ts_paint win on all platforms

RESOLVED WORKSFORME

Status

Testing
Talos
P4
normal
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: mconley, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

unspecified
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

Initial measurements on mozilla-central changeset 0093691d3715 comparing e10s to non-e10s shows the following data for Windows after several retriggers:

Win XP:

:) ts_paint             731.1 +/-  1% (6#)  [ -53.3%]     341.6 +/-  1% (6#)

Win 7:

:) ts_paint             865.8 +/-  1% (6#)  [ -55.4%]     385.9 +/-  2% (6#)

Win 8:

:) ts_paint             741.1 +/-  1% (6#)  [ -57.4%]     316.0 +/-  0% (1#)


These numbers are claiming that we've essentially halved the time it takes to show the browser chrome from a cold start.

That's a pretty bold claim. We should try to confirm this, because if it's true, it's a really epic perf win.
OS: Unspecified → Windows
Similar data from Linux 32 / 64:

Linux 32:

:) ts_paint             905.8 +/-  1% (6#)  [ -56.7%]     392.3 +/-  3% (6#)


Linux 64:

:) ts_paint             859.3 +/-  1% (6#)  [ -56.5%]     374.2 +/-  4% (6#)
Summary: Confirm e10s causes a ts_paint win on Windows → Confirm e10s causes a ts_paint win on Windows and Linux
Relevant Mossop in IRC:

1:46 PM <Mossop> Not terribly surprising, since the process isn't drawing the content area anymore
1:47 PM <Mossop> A question becomes, what matters most, time to paint the chrome area or time to paint chrome and the homepage?

Updated

3 years ago
tracking-e10s: ? → +
Duplicate of this bug: 1247980
Hey jmaher,

Does Mossop's hypothesis in comment 2 sound plausible? And do we care about painting the content in ts_paint, or just the browser UI?
Blocks: 1063169
Flags: needinfo?(jmaher)
Plausible - yes, that makes a lot of sense.

What do we want to really test?  Startup is about when a user launches the browser and can use it.  For ts_paint we are not doing session restore, but we are loading a really simple page.  This test measure the basics of getting the browser started and doing basic display.  Ideally it would measure when we could interact with the browser...oh, I dream.

Given the above definition, I would say we should be measuring to when the content page loads, but I am open to other thoughts.  We should think about session restore as well.
Flags: needinfo?(jmaher)
(In reply to Joel Maher (:jmaher) from comment #5)
> Plausible - yes, that makes a lot of sense.
> 
> What do we want to really test?  Startup is about when a user launches the
> browser and can use it.  For ts_paint we are not doing session restore, but
> we are loading a really simple page.  This test measure the basics of
> getting the browser started and doing basic display.  Ideally it would
> measure when we could interact with the browser...oh, I dream.
> 
> Given the above definition, I would say we should be measuring to when the
> content page loads, but I am open to other thoughts.  We should think about
> session restore as well.

The problem with this is that when the content page is loading in a separate process presumably it can finish loading before the main process has finished setting up the browser UI and I think we care about that here too, maybe more so since we have page load tests elsewhere.
do we need two tests?  maybe session restore can handle the content ready and ts_paint handles the 'chrome ready'?

Comment 8

2 years ago
(In reply to Dave Townsend [:mossop] from comment #6)
> The problem with this is that when the content page is loading in a separate
> process presumably it can finish loading before the main process has
> finished setting up the browser UI and I think we care about that here too,
> maybe more so since we have page load tests elsewhere.

I think that's pretty much impossible.
I just tested launching Nightly (on Win 7).
What I see:
after I clicked on the Nightly icon, it took 5 seconds to the UI show up. The plugin-container.exe showed up on the Windows Task Manager AFTER the UI was already in place.
(In reply to Guilherme Lima from comment #8)
> (In reply to Dave Townsend [:mossop] from comment #6)
> > The problem with this is that when the content page is loading in a separate
> > process presumably it can finish loading before the main process has
> > finished setting up the browser UI and I think we care about that here too,
> > maybe more so since we have page load tests elsewhere.
> 
> I think that's pretty much impossible.
> I just tested launching Nightly (on Win 7).
> What I see:
> after I clicked on the Nightly icon, it took 5 seconds to the UI show up.
> The plugin-container.exe showed up on the Windows Task Manager AFTER the UI
> was already in place.

Just because it doesn't happen now doesn't make it impossible. The point is to decide what the appropriate thing we're measuring is. Right now we're measuring something about the time to load the page. I don't think we want that.
Priority: -- → P4

Comment 10

2 years ago
Since this test listens for MozAfterPaint and presumably the test page is loaded remote, is the MozAfterPaint event we receive here tied to content only? If this is the case the measurement may not include flushing the layer updates over to chrome, latching those into the chrome layer tree, and flushing those bits to the screen. A test that measures all of this would generate an honest value tied to what the user actually sees when they launch Firefox.

tpaint is probably the same and should have a similar bug filed here, except for some reason we regress that test under e10s (bug 1174770). So maybe my content only theory here is wack.
Blocks: 1251547

Comment 11

2 years ago
(In reply to Jim Mathies [:jimm] from comment #10)
> Since this test listens for MozAfterPaint and presumably the test page is
> loaded remote, is the MozAfterPaint event we receive here tied to content
> only?

I took a look at MozAfterPaint more closely here - https://bugzilla.mozilla.org/show_bug.cgi?id=1254628#c2
Jim, is there anything left to do to confirm whether this ts_paint win is real?

https://treeherder.mozilla.org/perf.html#/e10s?filter=ts_paint
Depends on: 1254628
Flags: needinfo?(jmathies)
OS: Windows → All
Summary: Confirm e10s causes a ts_paint win on Windows and Linux → Confirm e10s causes a 40–50% ts_paint win on all platforms

Comment 13

2 years ago
Can't think of anything. Improvements in startup first paint seem reasonable to me, two processes sharing the work should help shorten the time to painting the window.
Flags: needinfo?(jmathies)
I'll let you resolve this bug WORKSFORME when you're ready. :)
I'm resolving this bug as WORKSFORME because it is not currently actionable. Plus the tests are green. \o/
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Depends on: 1287938
You need to log in before you can comment on or make changes to this bug.