972078 - CSS::ProcessRestyles takes 150ms flipping background color of 10,000 elements

Status: RESOLVED DUPLICATE of bug 1493420

(Core :: CSS Parsing and Computation, defect)

Description

[Benoit Girard (:BenWa)]

Attachment: tiling-worse-case.html

I'm writing a simple testcase to test worse case GFX tiling performance and I got a total hang. I reduced the test to 10,000 elements. This might not be the most realistic test case but it fells like the style system should be handle this much better so filing this so someone can investigate.

We seem to be spending too much time allocating memory here:
http://people.mozilla.org/~bgirard/cleopatra/#report=af823add5c9302981b3004d0956e428dd150874e

Comment 1

[Cameron McCormack (:heycam)]

I am surprised we are allocating memory here.  nsStyleBackground has an nsAutoTArray<Layer,1>, so that AppendElement call in the nsStyleBackground constructor shouldn't need any memory allocation.

Comment 2

[Cameron McCormack (:heycam)]

My mistake we're in the nsStyleBackground copy constructor, but even so, the initialization mLayers(aSource.mLayers) shouldn't need an allocation.

Comment 3

[Cameron McCormack (:heycam)]

OK so it looks like nsAutoTArray starts off with mHdr->mCapacity == 0 when constructed via a copy constructor, and so the AppendElements call that copies the elements from the other array calls EnsureCapacity and allocates storage.

Comment 4

[Cameron McCormack (:heycam)]

I would expect from glancing at nsTArray.h that the copy construction of mLayers would result in us using the nsAutoTArray copy constructor, which should then invoke the default constructor of nsAutoArrayBase, which calls Init to initialize our mCapacity.  This doesn't seem to happen.  Someone with a better grasp of our the array templates might be able to say why.

Comment 5

[Cameron McCormack (:heycam)]

Attachment: array patch

This avoids the array allocations.  The test is still very slow though.

Comment 6

[Cameron McCormack (:heycam)]

Without patch applied, I get an average of 515 ms per rAF callback run.  With patch applied, I get an average of 486 ms.  (Average of 50 runs.)

Comment 7

[Benoit Girard (:BenWa)]

A step in the right direction at least.

Comment 8

[Mayank Bansal]

1 second spent in styling : https://perfht.ml/2Nsud7s

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Same root cause as bug 1493420.