1159819 - investigate flexbox reflow performance during treeherder reflow & scrolling

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Scrolling / relayout on TreeHerder is slow. (& slower in Firefox Nightly than in Chrome)

Filing this bug on investigating to see if there are any obvious flexbox-related inefficiencies that we're hitting in Gecko and/or Treeherder code.

(See also bug 1159470 comment 0.)

Comment 1

[Daniel Holbert [:dholbert]]

One possible speedup here:

So TreeHerder has a top-level flex container (id="global-container"), whose second flex item is a large scrollable area ("th-content").

The outer flex container has to reflow its child (th-content) twice right now:
 (1) We reflow to measure its content, to resolve "flex-basis:auto;height:auto", to establish a flex base size for use in flex layout. (This "measuring reflow" produces a multi-thousand-px-tall size, since the content is large.)

 (2) We reflow it at its (much smaller) final size after we've run the flex layout algorithm.

We should be able to optimize away reflow #1 by replacing the current "flex:auto" (= 1 1 auto) in the .th-content rule with "flex:1" (= 1 1 0%)

I think all we want is for this element to absorb all the excess space; its flex basis doesn't particularly matter here, particularly given that this element is scrollable (overflow-y:auto)

Comment 2

[Daniel Holbert [:dholbert]]

The change in comment 1 here gives a ~20% speedup on Layout, running bz's test from bug 1159470 comment 0.

After loading 50 jobs & running bz's test script:
 default style: Layout takes 1480ms
 tweaked style: Layout takes 1180ms

After loading 100 jobs & running bz's test script:
 default style: Layout takes 2800ms
 tweaked style: Layout takes 2180ms

Comment 3

[Daniel Holbert [:dholbert]]

(Spun off bug 1162725 as a TreeHerder bug for comment 1 / comment 2.)

Comment 4

[Daniel Holbert [:dholbert]]

I also spun off bug 1162754 for an optimization that I realized we can make, to avoid measuring the height of the bottom panel (the panel that shows info about a particular build).

Comment 5

[Ed Morley [:emorley]]

Thank you for digging into this - much appreciated! :-)

Comment 6

[Daniel Holbert [:dholbert]]

I think this may've gotten an order of magnitude better (not sure if that's due to changes on the TreeHerder side vs. on the Firefox side... probably some of it is due to me having a faster machine, too).

If I follow bz's instructions from bug 1159470 comment 0, I now see these results in Firefox Nightly:

Style: 283
Layout: 233

which are ~1/5 the values from comment 0. Here's a profile from the run where I captured those ^ values: https://share.firefox.dev/3cR55Ek

Performing the same experiment in Chrome 83, I see results that are ~2x as slow:

Style: 447
Layout: 494

So it seems we're doing better than the competition, and quite a bit better than we were doing when this was filed, so it's unclear that there's any clear improvements that could/should be made here.

I think we can call this WORKSFORME.