Open
Bug 664818
Opened 14 years ago
Updated 2 months ago
Inline style setting improvements needed
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
NEW
People
(Reporter: bzbarsky, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
1.97 KB,
text/html
|
Details |
See attached testcase, one which we're somewhat slower than some of our competitors (though not than the ones that handle CSS selectors correctly).
This is basically reduced from http://jsperf.com/style-batching
Profile with the patches for bug 657724 shows:
7% in the .style get (slow stub call under JM)
5% double-to-string conversion and string concat in JS
2% array_pop
2% SetName stubcall
2% inline style quickstub time.
Then there's 77% under nsDOMCSSDeclaration::ParsePropertyValue, breaking down like so:
6% AttributeWillChange
5% GetCSSParsingEnvironment (a lot of this is GetBaseURI)
2% RemoveScriptBlocker
12% ParseProperty (ParseNumber, tokenization, etc).
5% nsCSSExpandedDataBlock::Compress
3% nsCSSExpandedDataBlock::Expand
3% nsCSSScanner::Init
2% nsCSSScanner::Close
2% nsCSSExpandedDataBlock::TransferFromBlock
4% StyleRule::DeclarationChanged (mostly malloc here)
11% AttributeChanged
7% Setting attrs (mostly refcounting style rules, calling free(), etc).
4% Attr-setting DOM code of various sorts
Reporter | ||
Comment 1•14 years ago
|
||
At least part of the problem is that padding-left is a shorthand; hence all the expand/compress stuff.... But even if I stick to .height a lot of the rest of that stuff is left.
Reporter | ||
Comment 2•14 years ago
|
||
Updated•2 years ago
|
Severity: normal → S3
Comment 3•2 months ago
|
||
With 100x the loopcount:
Firefox: 8.7s : https://share.firefox.dev/4dmRiFq
Chrome: 5s : https://share.firefox.dev/3WYEoI7
You need to log in
before you can comment on or make changes to this bug.
Description
•