Closed
Bug 72345
Opened 23 years ago
Closed 23 years ago
getComputedDOMStyle is too expensive
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
FIXED
mozilla0.9
People
(Reporter: hyatt, Assigned: hyatt)
References
Details
Attachments
(1 file)
See my upcoming post to n.p.m.performance. 9% of new navigator window time is spent resolving style on objects that *will* have frames (but that don't at the time the style resolution happens to determine the binding). We need the capability to cache resolved style contexts from GetComputedDOMStyle in a cache on the presshell. Frame construction can then check this cache to avoid doing a double-resolve.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 1•23 years ago
|
||
I will be adding a dump of the offending elements shortly.
Assignee | ||
Comment 2•23 years ago
|
||
Ok, with some clever limiting on my end, I cut it from 9% to 5%, but the remaining 5% all have bindings that must be loaded (and thus are a legitimate problem). Attaching the patch to cut the calls to GetComputedDOMStyle from 55 down to 17. I notice that 3 of the 17 calls are from nsGenericElement (in other words, non-XUL elements). I'll investigate that next.
Assignee | ||
Comment 3•23 years ago
|
||
Assignee | ||
Comment 4•23 years ago
|
||
Ok, the three HTML elements are: HTML, HTML, and INPUT. The two <html> tags are from about:blank. There are two because about:blank is loaded twice (the source of another bug). The reason <html> has the computed DOM style check done is the scrollbars. The scrollbar is parented to the <html> element, and the creation of the scrollbar script object forces the creation of the <html> script object, but no frame is in the map for it yet. Stopping about:blank from having scrollbars (another bug I've filed) will fix this. The input element is in the XUL document, and it needs bindings, so it's ok. I'm going to work now on eliminating scrollbars from about:blank and on stopping the double load. The time from this should go down even further.
Assignee | ||
Updated•23 years ago
|
Summary: Need a style context cache to avoid double-resolves prior to frame construction → getComputedDOMStyle is too expensive
I'm normally worried about special cases like this, but my need for speed overrules. sr=shaver.
Comment 6•23 years ago
|
||
r=jag
Assignee | ||
Comment 7•23 years ago
|
||
With the about:blank patches, I'm down to 13, and 4%, for a 5% speedup. All right!
Comment 8•23 years ago
|
||
sr=scc
Comment 9•23 years ago
|
||
a=brendan@mozilla.org for checkin to the 0.8.1 branch -- hyatt, please get this patch in. Thanks, /be
Assignee | ||
Comment 10•23 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 11•23 years ago
|
||
Did you check this into the 0.8.1 branch too? bonsai suggests only trunk...
Assignee | ||
Comment 12•23 years ago
|
||
I don't want to put this in the branch.
Comment 13•23 years ago
|
||
hyatt: you have final say, but we drivers@mozilla.org thought this was a 0.8.1 candidate. No worries, and please do say more about why you think this should not go on the branch. /be
Assignee | ||
Comment 14•23 years ago
|
||
There is a risk of regressions... bindings not being installed. I want to see it shake out first.
You need to log in
before you can comment on or make changes to this bug.
Description
•