Record stacks of when services are loaded
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: nalexander, Assigned: florian)
References
Details
Attachments
(4 files)
Bug 1398198 captures JS stacks when JS components and modules are loaded. I am digging into details of when various XPCOM services are loaded very early in startup, and wanted to record stacks to help me understand this.
So I added this, and learned some things, including that capturing native stacks isn't particularly useful. But having done it I thought I would post it and see if we might land it: perhaps it can be made more useful (by adding optional JS stacks, or getting mixed stacks like the profiler/BHR).
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Comment 2•4 years ago
|
||
DO NOT LAND: This functionality is slow; it should be put behind a
second environment variable and pref pair.
Depends on D91371
Assignee | ||
Comment 3•4 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #0)
So I added this, and learned some things, including that capturing native stacks isn't particularly useful. But having done it I thought I would post it and see if we might land it: perhaps it can be made more useful (by adding optional JS stacks, or getting mixed stacks like the profiler/BHR).
Have you considered adding profiler markers? Here is a startup profile on my local build with the attached patch, which adds GetService
markers a some more label frames: https://share.firefox.dev/342LWNr
Assignee | ||
Comment 4•4 years ago
|
||
FWIW, I worked on bug 1398198 several years ago, and given how much the profiler has progressed since that, if I worked on the browser_startup.js test today, I would likely remove most of the startup recorder, and instead make the test read markers from a startup profile (similar to the https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_startup_mainthreadio.js test that I wrote more recently, and that has code to extract markers from the JSON data of a profile, and read their stacks).
Reporter | ||
Comment 5•4 years ago
|
||
Florian -- thanks for your thoughts in this area. I have kinda-sorta considered using profiler markers and rejected it because of the unusual use case that I have. We're investigating a non-standard startup path that would be used to run certain JS code from the command line as a background task, and in that context it's not clear to me if/how much of the profiler would be available.
But... having pursued this patch as a learning exercise, and having found out why capturing these stacks wasn't done in the first place, I'll abandon this particular technical expression in favour of thinking through the role of the profiler in our use case.
Thanks again, Florian!
Assignee | ||
Comment 6•4 years ago
|
||
Is the profiler hard to use in your case? For cases where using the profiler UI is difficult, what usually works is using startup+shutdown profiling. This dumps a JSON file to the disk, and we can them symbolicate it either using python scripts (we do this for mochitests and talos profiles) or when loading the profile into profiler.firefox.com (eg. dropping the file on the page) in the same local build.
Should I request review for my patch in this bug? Or open a follow-up?
Assignee | ||
Comment 7•4 years ago
|
||
After discussing with Nick, we concluded the profiler will be usable for his use case, so I'll request review of my patch here.
Assignee | ||
Comment 8•4 years ago
|
||
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Reporter | ||
Comment 11•4 years ago
|
||
Clearing NI since this has landed. Thanks, Florian!
Reporter | ||
Updated•4 years ago
|
Description
•