Open Bug 664818 Opened 11 years ago Updated 8 years ago
Inline style setting improvements needed
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
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.
You need to log in before you can comment on or make changes to this bug.