Bugzilla

To summarize my understanding, the issue is that the script cache slow loads some scripts which we expect to be cached. There are two root causes (which :bdahl mentioned in [comment 9](https://bugzilla.mozilla.org/show_bug.cgi?id=1623518#c9)):
1. Some scripts in the child process run before the ScriptPreloader is ready to cache them
2. The ScriptPreloader in the child process returns its cached scripts to the parent process before all start up scripts have finished running

You can see the timing in the markers in this profile from a recent fenix Nightly: https://share.firefox.dev/34oRUMh You can roughly see `IPCIn — PContent::Msg_PScriptCacheConstructor` for when the ScriptPreloader is init and `IPCOut — PScriptCache::Msg___delete__` for when the child process sends its cache to the parent. The `GeckoViewStartup.jsm` script occurs during init and is not cached (bug 1; details on caching below). `ExtensionProcessScript.jsm` occurs after init and is cached. `ContentMetaChild.jsm` occurs just before `___delete__` and is not cached (bug 2).

I was able to identify which scripts are cached and which aren't by parsing the JSComponentLoader logs with [this script](https://github.com/mozilla-mobile/perf-tools/pull/27). Here's a typical COLD VIEW for the child process:

This pattern generally holds – ~18 child process scripts cached (and all the parent process scripts cached) – for both COLD MAIN and COLD VIEW if there is a page load.

---

In my investigation, I found one more issue: if the previous session didn't load any pages, the next session will have to slow load all of the scripts. This seems likely to happen when the previous process was started from a background job. I filed Bug 1753336.

To summarize my understanding, the issue is that the script cache slow loads some scripts which we expect to be cached. There are two root causes (which :bdahl mentioned in [comment 9](https://bugzilla.mozilla.org/show_bug.cgi?id=1623518#c9)):
1. Some scripts in the child process run before the ScriptPreloader is ready to cache them
2. The ScriptPreloader in the child process returns its cached scripts to the parent process before all start up scripts have finished running

You can see the timing in the markers in this profile from a recent fenix Nightly: https://share.firefox.dev/34oRUMh You can roughly see `IPCIn — PContent::Msg_PScriptCacheConstructor` for when the ScriptPreloader is init and `IPCOut — PScriptCache::Msg___delete__` for when the child process sends its cache to the parent. The `GeckoViewStartup.jsm` script occurs during init and is not cached (bug 1; details on caching below). `ExtensionProcessScript.jsm` occurs after init and is cached. `ContentMetaChild.jsm` occurs just before `___delete__` and is not cached (bug 2).

I was able to identify which scripts are cached and which aren't by parsing the JSComponentLoader logs with [this script](https://github.com/mozilla-mobile/perf-tools/pull/27). I attached the output of a typical COLD VIEW. The pattern shown generally holds – ~18 child process scripts cached and all the parent process scripts cached – for both COLD MAIN and COLD VIEW if there is a page load.

---

In my investigation, I found one more issue: if the previous session didn't load any pages, the next session will have to slow load all of the scripts. This seems likely to happen when the previous process was started from a background job. I filed Bug 1753336.

To summarize my understanding, the issue is that the script cache slow loads some scripts which we expect to be cached. There are two root causes (which :bdahl mentioned in [comment 9](https://bugzilla.mozilla.org/show_bug.cgi?id=1623518#c9)):
1. Some scripts in the child process run before the ScriptPreloader is ready to cache them
2. The ScriptPreloader in the child process returns its cached scripts to the parent process before all start up scripts have finished running

You can see the timing in the markers in this profile from a recent fenix Nightly: https://share.firefox.dev/34oRUMh You can roughly see `IPCIn — PContent::Msg_PScriptCacheConstructor` for when the ScriptPreloader is init and `IPCOut — PScriptCache::Msg___delete__` for when the child process sends its cache to the parent. The `GeckoViewStartup.jsm` script occurs during init and is not cached (bug 1; see attachment for which scripts are cached). `ExtensionProcessScript.jsm` occurs after init and is cached. `ContentMetaChild.jsm` occurs just before `___delete__` and is not cached (bug 2).

I was able to identify which scripts are cached and which aren't by parsing the JSComponentLoader logs with [this script](https://github.com/mozilla-mobile/perf-tools/pull/27). I attached the output of a typical COLD VIEW. The pattern shown generally holds – ~18 child process scripts cached (the rest are slow loaded) and all the parent process scripts cached – for both COLD MAIN and COLD VIEW if there is a page load.

---

In my investigation, I found one more issue: if the previous session didn't load any pages, the next session will have to slow load all of the scripts. This seems likely to happen when the previous process was started from a background job. I filed Bug 1753336.