608648 - Changing div backgroundColor is slow compared to Chrome (Peacekeeper grid tests)

Status: NEW

(Core :: Layout, defect)

Description

[Trev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101031 Firefox/4.0b8pre

In tests 2, 3, and 4 of peacekeeper, it builds a grid of divs and then just changes the style.backgroundColor of each div.  The difference between each test is just the number of divs, with test 2 having very few and test 4 having a lot.

You can run test 4 at http://www.peacekeeper.therichins.net/test3b.html.  On my Windows XP box, I get the following numbers:

FF4: 5.069
Chrome7: 12.172

I tested it with "layers.accelerate-none" set to true and "layers.accelerate-all"  set to false as well and the FPS was:

FF4: 5.302

The line that is the major bottleneck is:

this.pixels[y][x].style.backgroundColor = this.hex(c, Math.round(c / 2), 0);

I've tried all the following changes and each one caused FF4 to be faster than Chrome.

1 - Commented out the line
2 - this.pixels[y][x] = this.hex(c, Math.round(c / 2), 0);
3 - this.pixels[y][x].style.backgroundColor = '#000000';
4 - this.pixels[1][1].style.backgroundColor = this.hex(c, Math.round(c / 2), 0);

I also tested with different number of divs.  Around 169 divs (13x13) is when FF4 becomes slower than Chrome.

I found bug 147796 which looks to be similar to this, but it dealt specifically with Linux.

Reproducible: Always

Steps to Reproduce:
1. Load http://www.peacekeeper.therichins.net/test3b.html in FF4 and Chrome
2. Notice that the avg FPS for FF4 is below Chrome
Actual Results:  
FF4 is slower than Chrome

Expected Results:  
FF4 to be as fast or faster than Chrome

Comment 1

[Boris Zbarsky [:bzbarsky]]

Thanks for the testcase!  If it's standalone, do you want to just attach it to this bug?

The time breakdown on Mac (where Chrome is about 3x faster than us) is like so:

  39% painting (18% building display lists and layers; 18% cairo actually
      painting, rest is Clip() and other noise)
  
  16% doing the actual background color sets and all associated JS (12% for the
      sets themselves).

  45% restyle processing.  This breaks down as:
     1% restyle tracker hashtable ops
    12% ProcessRestyledFrames (about 2/3 in the InvalidateOverflowRect() calls)
    11% ResolveStyleFor (actual rule matching is 6%; the GetContext call is 4%,
        the latter because it has to do the style fixups, which is forcing a
        WalkRuleTree looking for the display data and a ComputeDisplayData
        call).
     9% CalcStyleDifference (getting, and recomputing, position and background
        structs).
     7% ruletree GC.
     and some minor stuff.

I'll try to figure out why we're recomputing display structs here, exactly.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, right.  All the "pixels" have float:left, so we can't cache the display struct in the ruletree.  That's.... annoying.

And the reason we're recomputing position structs is that the pixel width/height are all specified as inline style instead of via a class, so the position struct is cached right on the rulenode for the inline style rule.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I filed bug 608756 on the display struct thing, but we need a bunch more bugs filed on the slow bits here...

The InvalidateOverflowRect stuff might go away in bug 539356.

Some other noise that might go away is the rule processor data ctors/dtors (bug 598832).

Comment 4

[Trev]

Attachment: test3b.html

Comment 5

[Harsh86]

I believe this is rederGrid03 in Peacekeeper 2.0. Fx Nightly is currently 3-4x slower than Chrome Dev in that benchmark.

Comment 6

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I just redid a profile of the testcase from comment 4. Still on Mac.

40% is restyle processing; this breaks down about evenly as ResolveStyleFor,
    CalcStyleDifference, ruletree GC, and the invalidate calls we make.
14% JS execution plus style setting (10% for the actual style sets)
45% painting.  Building display lists is only 6% now, but another 6% is
    ComputeVisibilityForRoot, 5% is building layers, and the rest is almost entirely
    nsDisplayBackground::Paint).

So not much changed, really.  I wonder whether the paint time is less on Windows....

Comment 7

[Trev]

On Windows XP, nightly has jumped very nicely.  There are three render grid tests: 10x5, 25x20, 85x50 (which is test3b.html).  My numbers of yesterday, today and chrome.

       Yesterday    Today   Chrome
10x5:      88.46   166.34   167.96
25x20:     70.32   103.42   164.93
85x50:      4.95     5.15    17.79

Comment 8

[Boris Zbarsky [:bzbarsky]]

What changed from yesterday to today?  I really hope that jump is not from bug 608756 alone!

Comment 9

[Trev]

No, it turns out it is the setTimeout thing.  I just did a reboot Between yesterday and today, the timer resolution must have been turned up so instead of being clamped to around 10ms, I was clamped to around 1ms.  So, with the normal clamp, the times are:

       Yesterday    Today   Chrome
10x5:      86.45    87.28   140.40
25x20:     70.32    75.81   150.03
85x50:      4.95     5.24    18.22

It would be nice if Bug 640796 was fixed.

Comment 10

[Guilherme Lima]

On the testcase from comment #4 I get

Nightly - Avg: 5.828
Chrome 33 - Avg: 13.204
IE 11 - Avg: 8.750

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

We're way slower on linux than chrome, and https://bugzilla.mozilla.org/show_bug.cgi?id=608648#c1
is still valid.