Boris Zbarsky [:bzbarsky] Reporter
	Description • 13 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 1 • 13 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.