CustomElementReactionsStack::PopAndInvokeElementQueue() shows up in performance profiles

RESOLVED FIXED in Firefox 57

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 months ago

People

(Reporter: smaug, Assigned: jdai)

Tracking

(Blocks 1 bug)

unspecified
mozilla57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

CustomElementReactionsStack::PopAndInvokeElementQueue() shows up in performance profiles even if dom.webcomponents.customelements.enabled and dom.webcomponents.enabled both are false.
In this case it is in set_value in HTMLInputElementBinding.cpp (generated code).
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
Assignee

Updated

2 years ago
Assignee: nobody → jdai
Assignee

Comment 3

2 years ago
Posted patch patch, v1 (obsolete) — Splinter Review
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
Attachment #8900127 - Flags: review?(bugs)
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.
Attachment #8900127 - Flags: review?(bugs) → review-
Assignee

Comment 5

2 years ago
(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.
Assignee

Comment 6

2 years ago
Posted patch patch, v2Splinter Review
Address comment 4.
Attachment #8900127 - Attachment is obsolete: true
Attachment #8900173 - Flags: review?(bugs)
Attachment #8900173 - Flags: review?(bugs) → review+
Assignee

Updated

2 years ago
Keywords: checkin-needed

Comment 7

2 years ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e2a544ea360c
Avoid doing [CEReactions] if custom element preference is disabled. r=smaug
Keywords: checkin-needed

Comment 8

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e2a544ea360c
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
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
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.