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

Status: RESOLVED WORKSFORME

(Testing :: Talos, defect, P4)

Description

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

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

Comment 2

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 6

[Dave Townsend [:mossop]]

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

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

do we need two tests?  maybe session restore can handle the content ready and ts_paint handles the 'chrome ready'?

Comment 8

[Guilherme Lima]

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

Comment 9

[Dave Townsend [:mossop]]

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

Comment 10

[Jim Mathies [:jimm]]

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.

Comment 11

[Jim Mathies [:jimm]]

(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

Comment 12

[Chris Peterson [:cpeterson]]

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

Comment 13

[Jim Mathies [:jimm]]

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.

Comment 14

[Chris Peterson [:cpeterson]]

I'll let you resolve this bug WORKSFORME when you're ready. :)

Comment 15

[Chris Peterson [:cpeterson]]

I'm resolving this bug as WORKSFORME because it is not currently actionable. Plus the tests are green. \o/