Tp Ts Txul regression on bl-bldlnx03_fx-linux-tbox-head on 20080218

RESOLVED INCOMPLETE

Status

()

Core
CSS Parsing and Computation
RESOLVED INCOMPLETE
10 years ago
10 years ago

People

(Reporter: stevee, Unassigned)

Tracking

({perf, regression})

Trunk
perf, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Updated

10 years ago
Summary: Tp regression on bl-bldlnx03_fx-linux-tbox-head (241ms-->245ms) on 20080219 → Tp Ts Txul regression on bl-bldlnx03_fx-linux-tbox-head on 20080218
Hrm, I'd clicked a whole bunch of graph links and didn't see anything that bad.  Sayrer did point out a slight Txul regression that showed up on the XP and maybe Mac talos boxes (and it looks like the Txul regression is the worst one here).

I think some of this may be unavoidable -- the bug was that we weren't doing enough work; we have to do more work to fix that.  I started looking into which selectors / elements we were actually hitting that case on, but got pulled away.
Component: General → Style System (CSS)
OS: Windows XP → All
QA Contact: general → style-system
Hardware: PC → All
Things to investigate:
 * is the extra time the testing whether we need to restyle or the actual restyling
 * if the latter, what selectors/elements are causing us to take the slow path?
 * if the latter, does setting the flags in SelectorMatches more precisely by using a variable and holding off until the end of the function help?
I'm going through and marking old performance regression bugs as INCOMPLETE that are likely too old to be valid or get any traction on them.

Please re-open if you have more information or can demonstrate the regression still exists (specifically the stuff dbaron lays out in comment 4)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.