CustomElementReactionsStack::PopAndInvokeElementQueue() shows up in performance profiles

RESOLVED FIXED in Firefox 57

Status

()

RESOLVED FIXED
a year ago
a year ago

People

(Reporter: smaug, Assigned: jdai)

Tracking

(Blocks: 1 bug)

unspecified
mozilla57
Points:
---

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

a year ago
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

a year ago
Assignee: nobody → jdai
(Assignee)

Comment 3

a year ago
Created attachment 8900127 [details] [diff] [review]
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
Attachment #8900127 - Flags: review?(bugs)
(Reporter)

Comment 4

a year ago
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

a year 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

a year ago
Created attachment 8900173 [details] [diff] [review]
patch, v2

Address comment 4.
Attachment #8900127 - Attachment is obsolete: true
Attachment #8900173 - Flags: review?(bugs)
(Reporter)

Updated

a year ago
Attachment #8900173 - Flags: review?(bugs) → review+
(Assignee)

Updated

a year ago
Keywords: checkin-needed

Comment 7

a year 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

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e2a544ea360c
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox57: --- → fixed
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
You need to log in before you can comment on or make changes to this bug.