481128 - HTML5 is slow to load

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[Hixie (not reading bugmail)]

HTML5 is slow to load in Firefox.

Specifically, the time to parse and lay out the document is slower than other browsers (Opera and Webkit in particular).

TESTCASE
   http://damowmow.com/playground/bugs/slow/html5/001/?slow-browser

There's a tarball:
   http://damowmow.com/playground/bugs/slow/html5/001/html5-perf-001.tar.gz
   http://damowmow.com/playground/bugs/slow/html5/001/README

You have to run the test case with "?slow-browser" on the end of the URL to disable the scripts, which would detract from the load issue.

Comment 1

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

See also bug 475721.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Fwiw, over here webkit trunk loads in about 5.5 seconds uncached, 3.5 seconds cached.  Opera 9.6 is 14s uncached, 11s cached.  Firefox trunk is 11s uncached, 7s cached.

Working on getting some profiles now.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Lessee.  20% reflowing off reflow events.  Another 15% reflowing off paint events via [NSView _drawRect:clip:] calling [ChildView drawRect:].  Another 15% reflowing off paint events via [NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] calling _drawRect:clip: and then as above.  That's 50% of pageload right there.  Compositor might or might not help with this.

nsBidiPresUtils::Resolve takes about 6% of total pageload (so about 1/9 of reflow or so).

3% is restyle processing from painting, with stacks as for reflow above.  2% is actual painting.

About 25% of the time is under nsCSSFrameConstructor::ContentAppended.  A bunch of that is style resolution (e.g. 15.6% of that 25% is in, not under, SelectorMatches).  To be precise, about 13% of total pageload is under ResolveStyleContext.  40% of that is RuleProcessorData construction, the rest FileRules.  The remainder of the ContentAppended time is spread over various other parts of frame construction.

In other words, typical "big page load" profile.  :(

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm seeing more like 10% of the time under ContentAppended, and 40% of the time under ViewportFrame::Reflow.  Did reflow here get worse somehow?  Maybe I should try again with ireflow disabled...

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: probably not a useful patch

So earlier today I was under the impression that the spec took so long to load that I wasn't able to wait for it to finish... although I think that was actually just under callgrind instrumentation.  (Though I'd thought I'd checked uninstrumented too.)

In any case, I debugged things a little, suspecting (and seeing, in reflow dumps) an O(N^2) reflow problem, and wrote this patch to fix the case where lines were erroneously (in my opinion) being marked dirty.

But I think I was somehow imagining the performance problem being as bad as I thought it was, and I really don't know if this would help much.


I'm also not convinced of the correctness of this patch in the presence of incremental reflow, although I think it's probably right.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> and 40% of the time under ViewportFrame::Reflow.  Did reflow here get worse
> somehow?

Note that in comment 3 50% of the time was under reflow.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Current numbers (on a much bigger spec) are 12s cached for Gecko and 10s cached for webkit.

Comment 8

[ovidiu boca[:Ovidiu]]

This issue is still reproducible, I tested it with Mac OS X 10.14 and Windows 10 on Nightly 67.0a1(2019-03-12), Beta 66.0b14 and Release 65.0.2.

I used this site: https://www.alpacaprojects.com/inferno/en/

STR:

1. Open the site https://www.alpacaprojects.com/inferno/en/
2. Start the game
3. Select some characters

Comment 9

[Boris Zbarsky [:bzbarsky]]

What does comment 8 have to do with this bug and its original steps to reproduce?

Comment 10

[ovidiu boca[:Ovidiu]]

We filed a separate bug for that specific site, please see bug 1535276.

Comment 11

[Gregory Pappas [:gregp]]

This test case is very fast now.