If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TreeMatchContext ctor shows up in some profiles

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
5 years ago
5 years ago

People

(Reporter: smaug, Unassigned)

Tracking

({perf, regression})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
I was doing some MutationObserver profiling (lots of setAttribute calls)
and noticed some odd GetInterface/QueryInterface/Addref/Release stuff from style engine.
Looks like the problem is TreeMatchContext ctor
http://hg.mozilla.org/mozilla-central/diff/cf941140cded/layout/style/nsRuleProcessorData.h

Would mDocument->GetWindow()->GetDocsShell() and then add helper to get private
browsing flag in a fast way from docshell help here?
Or should we add a flag to document that it is in private browsing docshell?
The really silly thing is that as far as I can tell in the attr-change case we set up the tree match context with eLinksVisitedOrUnvisited in which case afaict the private browsing mode simply doesn't matter...  Can we maybe just skip getting it in this case?

Then again, I don't understand the comment in nsCSSRuleProcessor::GetContentState that purports to explain why the bit-twiddling cannot happen in GetContentStateForVisitedHandling, so maybe I'm missing something.
Ah, I guess there's a second caller of GetContentState, which is what that comment may be about...

In any case, that second caller is irrelevant for the eLinksVisitedOrUnvisited case as far as I can tell.
Keywords: perf, regression
You need to log in before you can comment on or make changes to this bug.