1243773 - nsNthIndexCache::SiblingMatchesElement is slow or it is called too often

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

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

I was profiling the cleopatra UI a bit, since opening the callstack tree (or what to call it) can effectively hang the whole browser.
In this particular profile 80% of cpu time is spent _in_ nsNthIndexCache::SiblingMatchesElement. Not under it, but inside that method.

Given that the method is very simple and inlined, perhaps the caller should be modified?
or cleopatra UI?

Comment 1

[Benoit Girard (:BenWa)]

Cleopatra does start chocking for certain profile size. Usually the default as such that it falls below that threshold but it might not depending on multiple factor. Is the Nth stuff the part that used to color even and odd rows? I'd be open to ways of improving cleopatra for these.

Comment 2

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

So we end up going through the loop
http://mxr.mozilla.org/mozilla-central/source/layout/style/nsNthIndexCache.cpp?rev=ac426472ceec&mark=128-136#128
lots of times.
I _guess_ we clear some cache, then go through the loop, then something is added to the tree-view which
cleopatra uses and then we clear the cache again and start from the beginning... something like that.
I see the loop going through thousands of iterations (==siblings)


removing the following in tree.css seems to drop this case from the profiles.
.treeViewTreeInnerContainer>:nth-child(2n+1) {
  background-color: white;
}
.treeViewTreeInnerContainer>:nth-child(2n) {
  background-color: #f0f5ff;
}
The UI is still slow, but bottleneck is now more in reflow side.
(cleopatra should probably use some different kind of tree-view component. Something which works also with lots of rows - meaning that the data model would be kept separately and there would be only dom elements for as many entries as what can be visible in the view port at a time)

Comment 3

[Jonathan Watt [:jwatt]]

nsNthIndexCache is now dead.