664818 - Inline style setting improvements needed

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 3

[Mayank Bansal]

With 100x the loopcount:

Firefox: 8.7s : https://share.firefox.dev/4dmRiFq
Chrome: 5s : https://share.firefox.dev/3WYEoI7