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




3 years ago
4 months ago


(Reporter: smaug, Unassigned)


36 Branch

Firefox Tracking Flags

(Not tracked)




3 years ago
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?
Component: Layout → CSS Parsing and Computation
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

3 years ago
So we end up going through the loop
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)
nsNthIndexCache is now dead.
Last Resolved: 4 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.