Closed Bug 1288563 Opened 8 years ago Closed 4 years ago

chromium source code indexer is very slow in Gecko

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: smaug, Unassigned)

References

(Blocks 1 open bug)

Details

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.cpp?l=2236 as an example. All the time is spent in reflow which is usually triggered by .offsetTop.
I tested in Firefox 48 and 50, and I didn't see significant slowness in the page you mentioned. What operation did you do makes you feel slow? Did you test that with safe mode or a clean profile?
Flags: needinfo?(bugs)
Loading that page is super slow. It seems to be the left sidebar takes time, I think. https://cleopatra.io/#report=77477e58d6176b2150774a51db19277aa1ef3ab2
Flags: needinfo?(bugs)
Hmmm, it doesn't seem I can reproduce this issue locally on Mac. I saw offsetTop triggers some flush, but the majority of that is just restyling. Did you reproduce this with a clean profile? I wouldn't be surprised if there is any addon which touches the tree frequently and consequently causes lots of additional reflow. Also ni?dholbert as large part of the layout in the profiling report involves flexbox, so probably there is something we can improve in general?
Flags: needinfo?(dholbert)
I can reproduce this issue with nightly and linux. Clean profile.
I guess the reason here is that we do much more reflow than necessary. There are two nested flexbox wrapping the source code, and it seems we reflow content of every flexbox twice (which seems to be another vulnerable O(2^n) performance issue), so nestedly, we reflow the source code 4times every time we flush the layout. Lots of reflow seems to be avoidable because both flexboxs seem to have only one child with non-constant width. I guess we should be able to only reflow everything in one pass, and check if the child with variable width needs to be reflowed with a different width again. (I'm not familiar with flexbox, though, so I could be missing something.)
(In reply to Olli Pettay [:smaug] (vacation Apr 15-20) from comment #0) > https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.cpp?l=2236 > as an example. This now triggers "Could not resolve path src/third_party/WebKit/Source/core/dom/Node.cpp", but here's another long source file, in a directory with lots of contents, to stress-test this: https://cs.chromium.org/chromium/src/third_party/sqlite/sqlite-src-3220000/src/expr.c Here are two profiles that I captured of this pageload in today's Nightly (filtered for nsFlexContainerFrame) https://perfht.ml/2JbXbqB (404ms total in nsFlexContainerFrame) https://perfht.ml/2qK1P8q (670ms total in nsFlexContainerFrame) In both cases, around 40% of that time in in a single long reflow, and the rest is from a series of short (mostly script-triggered) reflows.

[I'm doing a retriage of flexbox-perf-bug dependencies to see which ones are still a problem.]

The sqlite URL from comment 6 doesn't work anymore (the file moved/disappeared), but here's the modern version of the same file, I think (6000 lines long):
https://source.chromium.org/chromium/chromium/src/+/master:third_party/sqlite/src/src/expr.c

Here's a profile I captured of that pageload, in current Nightly (filtered for DoReflow): https://share.firefox.dev/3dSZ2QS

The metrics are similar to comment 6:

  • 367ms total spent in ::DoReflow
  • The longest individual reflow is 191ms

HOWEVER - I also captured a profile in Chrome 83, and they have pretty much the exact same results! Here's my Chrome profile (on the "marker chart" tab, filtered for "Layout"). Look at the second row in the marker chart, for Layout (not the other LayoutFooBar rows):
https://share.firefox.dev/3e4mwCU

Observations:

  • Their longest layout event is 191ms (exactly the same as in my Firefox profile).
  • They have a long tail of shorter-but-still substantial reflows as you seek backwards from that one (in reverse order, the Layout-event durations are 191, 56, 21, 16, 22, and then there are some that are on the order of 1-2ms.) These sum to 306ms (not including the short 1-2ms ones).
  • So their total amount of time spent in reflow is in the same ballpark as in Firefox (367ms vs. 306ms-plus-some-fudge-factor-for-a-bunch-of-small-layouts-that-I-didn't-bother-adding-up), and their longest individual reflow is the same duration as in Firefox (191ms).

So, to the extent that there's layout jank here, it's cross-browser layout jank and hence is probably attributable to the site (& just problems inherent with large amounts of content), and not to a Firefox-specific bug.

So I think we can call this WORKSFORME -- smaug, what do you think? (Perhaps you could sanity-check me and see if you're seeing a noticeable difference between Firefox and Chrome on your machine?)

Flags: needinfo?(dholbert) → needinfo?(bugs)

Chromium code search has changed, you need to go to cs.chromium.org. The file equivalent to Olli's is https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/node.cc?q=node.cc&dr

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Chromium code search has changed,

(Maybe changed in such a way that the original issue that Olli was hitting doesn't reproduce anymore?)

The file equivalent to Olli's is https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/node.cc?q=node.cc&dr

For me, that URL redirects to https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/dom/node.cc which is the same viewer as my "expr.c" link from comment 7.

Just in case there's a substantial difference between these two files, I profiled this node.cc pageload in Firefox Nightly 79 and Chrome 83 (as in comment 7). But my results are basically the same as in comment 7 -- the browsers spending basically the same amount of time in layout (and in this case, we came out a little better)

Here's a profile of me loading that node.cc page in Firefox Nightly 79: https://share.firefox.dev/3hpSV8Y
(filtered for DoReflow to show layout time)

Here's a profile in Chrome 83: https://share.firefox.dev/3cYw1SL
(in the marker chart, filtered for Layout)

Observations:

  • Both browsers have a handful of long reflows, though we look a bit better. (Our longest is 128ms, and the rest are under 100ms; Chrome's longest three are all longer than that (216ms, 147ms, 139ms).
  • Firefox's total time spent in DoReflow is 479ms. Chrome's time is more than that, even if you only consider the three above-mentioned long reflows (which sum to 502ms).

So if anything, we're looking better than Chrome here on time-spent-in-reflow.

You need to click "Return to Code Search v1" on the top right, fwiw :)

Aha, ok.

Still, with that version of the page: I'm not seeing "Very slow" (per bug title) / "super slow" (comment 2). The node.cc "code search v1" view feels approximately the same to me in Chrome and Firefox, and perf profiles seem to show similar layout durations.

Firefox: https://share.firefox.dev/3d5Zfzb
Chrome: https://share.firefox.dev/2YCYIzw

  • Both have lots of < 1ms reflows during the first half of the pageload
  • Both have a single ~80ms reflow (the longest of the recording) around 30-40% of the way through the pageload
  • For the last 30% of the recording, both have some slightly-longer reflows (in the 5ms-20ms range)

So: I'm still not seeing any substantial layout performance difference.

If anyone else does, please say so. Otherwise, I think this is very WORKSFORME. :)

I'm not seeing the slowness atm. This is an old bug, so I'll file a new one if I see this again.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.