Front.watchFronts API is having an uncessary performance impact on all fronts
Categories
(DevTools :: Framework, defect)
Tracking
(firefox105 fixed)
| Tracking | Status | |
|---|---|---|
| firefox105 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Bug 1780547 comment 0 STR highlights some slowness in Front implementation related to watchFronts API.
This is unfortunate as this API is rarely used:
https://searchfox.org/mozilla-central/search?q=.watchFronts%28&path=&case=false®exp=false
It would be nice to avoid emitting any event and create the EventEmitter only when we start using this API.
See this profile, where we spend some significant time in Front.unmanage (without the attached patch):
https://share.firefox.dev/3Suvk9L
~1100ms spent in Front.destroy
And this profile, where we still spend some time in Front.unamanage, but about half less (with the attached patch):
https://share.firefox.dev/3bGYPV9
~600ms spent in Front.destroy
I suspect this also has a significant impact when we instantiate all these fronts. Here I'm using bug 1780547 STR which is only about destruction.
|
Assignee | |
Updated•8 months ago
|
|
|
Assignee | |
Comment 1•8 months ago
|
||
The Front.watchFronts API is sparsly used whereas we always instantiate
two EventEmitter and emit two events for all the Fronts.
We can avoid doing that unless we start using this API only on a couple of fronts.
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bf52569d96ca [devtools] Avoid performance regression of Front.watchFronts API. r=nchevobbe
|
||
Comment 3•8 months ago
|
||
| bugherder | ||
Description
•