Closed Bug 1315331 Opened 8 years ago Closed 7 years ago

Gather telemetry for SDK add-on startup and loader performance

Categories

(Add-on SDK Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kmag, Assigned: kmag)

References

Details

After landing patches for bug 1308332, we had a hard time finding existing telemetry probes to give us useful data on the impact, and wound up falling back to ad-hoc analysis of thread hang data. In order to better track regressions in this area, especially in e10s, we should add probes for:

- Time spent in the 'sdk/addon/runner' run() function for each add-on, and/or the 'toolkit/loader' main() function. These functions do the bulk of loading and initialization for add-on code at startup.

- Total time spent in the loader's require() method, and time spent actually loading code (as opposed to overhead).

- Time spent in the loader's load() method, which does the actual loading work, and isn't always called by require().

Ideally, we should also try to get separate measurements for times shortly after startup (for both content and parent process) vs. later in the process lifecycle so we can gauge the specific impact on startup performance.
added ben, dave, and me to this card.  Kris, can you need info me when it's done so we can look at if we want to expand current beta metrics we are collecting?  Could be something that is looked at over time - also interesting with all the e10s, sandboxing, and multi changes if perf is impacted.
Flags: needinfo?(kmaglione+bmo)
At this point given the lifespan of the SDK I don't think we should be worrying about this.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kmaglione+bmo)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.