1392790 - CustomElementReactionsStack::PopAndInvokeElementQueue() shows up in performance profiles

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

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

CustomElementReactionsStack::PopAndInvokeElementQueue() shows up in performance profiles even if dom.webcomponents.customelements.enabled and dom.webcomponents.enabled both are false.

Comment 1

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

In this case it is in set_value in HTMLInputElementBinding.cpp (generated code).

Comment 2

[Jessica Jong [:jessica] (inactive)]

Oh, we do this for every operations, attributes, setters, or deleters annotated with the [CEReactions] extended attribute [1]. Can we check if the webcomponent preferences are enabled in our codegen?


[1] http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/dom/bindings/Codegen.py#7842-7851

Comment 3

[John Dai[:jdai]]

Attachment: patch, v1

In this patch, I add webcomponent preference check in order to avoid doing [CEReactions] when webcomponent preference are disabled.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=030c21cf02f706c3a9a4ffe70fda392373e922b6&filter-tier=1&group_state=expanded&selectedJob=125074622

Comment 4

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

Comment on attachment 8900127 [details] [diff] [review]
patch, v1

GetCustomElementReactionsStack call should be also inside IsCustomElementEnabled check.
Also, could we inline CustomElementRegistry::IsCustomElementEnabled().
This is extremely hot code after all.



Even once we enable custom elements, this code should be fast for documents which don't have any custom elements. But that optimization can be done in a different bug.

Comment 5

[John Dai[:jdai]]

(In reply to Olli Pettay [:smaug] from comment #4)
Thanks for your review.

> Comment on attachment 8900127 [details] [diff] [review]
> patch, v1
> 
> GetCustomElementReactionsStack call should be also inside
> IsCustomElementEnabled check.
Will do.

> Also, could we inline CustomElementRegistry::IsCustomElementEnabled().
> This is extremely hot code after all.
Sure. I will address them in next patch.

> 
> 
> 
> Even once we enable custom elements, this code should be fast for documents
> which don't have any custom elements. But that optimization can be done in a
> different bug.
File bug 1392974.

Comment 6

[John Dai[:jdai]]

Attachment: patch, v2

Address comment 4.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e2a544ea360c
Avoid doing [CEReactions] if custom element preference is disabled. r=smaug

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/e2a544ea360c

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

we see a performance improvement from this patch:
== Change summary for alert #8971 (as of August 23 2017 14:33 UTC) ==

Improvements:

  9%  dromaeo_dom summary linux64 pgo e10s     2,033.09 -> 2,208.32
  8%  dromaeo_dom summary linux64 opt e10s     1,920.19 -> 2,081.49

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=8971