560509 - AttributeWillChange and AttributeChanged take lots of time underneath PresShell

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: testcase

I'm talking about ~25% of setAttr or something like that.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

The testcase shows also a problem with tracing;
we seems leave the trace when passing JS Number to a method which expects
String.
(Not sure if bz already filed that as a separate bug.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

> we seems leave the trace when passing JS Number to a method which expects
> String.

That happens because then we don't hit the traceable native, and the fastnative uses JS_THIS_OBJECT, which deep-bails.  That's bug 556277, I think.  Jason, can you confirm?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Or perhaps bug 513065?

Comment 4

[Boris Zbarsky [:bzbarsky]]

General thoughts (which may well be bug-worthy; can someone file as needed?  some may already be filed) from profiling in my "nix rule processor data" build:

1)  We could keep track of all style-relevant attr names on the presshell or
    something, but the testcase actually has "foo" as a style-relevant attr, so
    that wouldn't help much.
2)  Of the nsFrameManager::HasAttributeDependentStyle time (which is 20-30% of
    the testcase time, depending on whether the attr is style-relevant or not),
    about half is spent under rule processor HasAttributeDependentStyle impls.
    The rest is non-virtual thunks, SheetHasAttributeStyle, etc.  Maybe worth
    making WalkRuleProcessors a template on the callback function, so that the
    callback function can actually be inlined?
3)  GetIDAttributeName and GetClassAttributeName are annoying.  Can we just
    assume that if there's an id or class (and there might not be one, for
    random XML) the attr will be called id or class?  That could win us some
    time here.
4)  A faster hashtable couldn't hurt.
5)  Making GetID faster couldn't hurt
6)  We seem to do a _lot_ of function calls here.  PGO or 64-bit probably help
    with that a lot.
7)  Maybe speed up nsAttrValue::Equals?  Not sure.
8)  Webkit uses a single hashtable for all selector attrs, looks like, and just
    checks whether there's an entry in it for the attr being changed.  So in
    this case it's a bit faster; it's simple to write cases where it's slower
    on the async actions that need to happen... so slower in cases when you
    don't set the same attr to 20000 different values in a row.