See Bug 1063635 See Bug 1063635#c10 This is done by lazily loading osfile (and its individual modules) if possible or investigating those functions which are called during startup.

Continuing the work from https://bugzilla.mozilla.org/show_bug.cgi?id=1063635#c8 of the given bug, some more results using perf-html profiler. * Currently, the first one to load osfile is GMPProvider.jsm followed by a very small usage by either CrashMonitor.jsm or SessionFile.jsm (varying on different startups). These seem to be the only users of the osfile in the first "event processing delay" on the main thread. Related profile: https://perfht.ml/2zDXoyL * On patching GMPProvider.jsm to use a `defineLazyModuleGetter`, the first one to load osfile is ExtensionParent.jsm, followed by some SessionFile.jsm or CrashMonitor.jsm. Note that this (ExtensionParent) was not there in the last profile in the first "event processing delay". Related profile: https://perfht.ml/2zDBsUw Based on this: 1. I'm unable to figure out why ExtensionParent is suddenly introduced to the startup even though it was not there previously (it uses a lazy getter as well already). Is there a way to investigate this? 2. I'm not sure why CrashMonitor and SessionFile only show up periodically (and in a seemingly random order). However, they seem to take up really small spaces on the time axis.

Apologies for the deal, I didn't see that needinfo. It might just be that there are race conditions and the code doesn't always load in the same order. For the moment, the biggest gain would be obtained by delaying the load of osfile_*.jsm, so I'd start by attempting to blacklist one of these (using http://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_startup.js ), then seeing what breaks and if it can be fixed.