The concerns that I have is that the start-up cache proved to be useful in multiple experiments made by 3 different persons, and at different occasions and for different purposes: - Bug 813324 - Compiled JS cache for Firefox - Bug 1101386 - Missing bytecode cache causes SpiderMonkey to be 6x slower than JSC at 2nd (or consecutive) execution of TypeScript-compiled code - Bug 1164389 - Allow certified applications to load XDR bytecode
So these numbers only highlight that using a bytecode cache is better than not using any, but they do not compare the caching the jschar-source against bytecode cache, and I would really appreciate to have this kind of information before doing these changes. Also note that in the previous tests, the bytecode cache only got used for caching the full bytecode, while today we are capable of saving a sparse version of the bytecode which only contains function used during the last execution, which reduces the bytecode cache size by 30%. So my concern is, that we are moving away from a system that we do not use optimally yet. On Tue, Nov 24, 2015 at 7:42 AM, Aaron Klotz <akl...@mozilla.com> wrote: > On 11/23/2015 10:22 PM, Mike Hommey wrote: >> >> Can the perf team look into this? Note the startup cache only matters >> on the first startup for a given build, and that might be a reason why >> we fail to track its performance impact. >> >> > We can get rid of it if we properly encode JS source in the omnijar. Unless > something has changed in SpiderMonkey, the last time I looked we convert the > JS source in the omnijar to jschars at parse time. Eliminating that > conversion step would cancel out the benefit of the startup cache. > > I seem to remember NBP expressing concern with this plan in Whistler. > Nicolas, do you recall what your concerns were? -- Nicolas B. Pierron _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
