I have a short summary of why caching JIT code is not necessarily a clear win for most JS in a blog post: http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching We do machine code for asm.js, though (as also described in the post).
More interesting than caching machine code is caching other bits of data that offer a lot more win per byte: - function boundaries and whether there were any SyntaErrors (so we don't have to do the initial syntax-only parse) - bytecode for the top-level script and definitely-run functions (usually this stuff is pretty cold, so bytecode is as far as it ever gets) - for the functions that do get jitted: which ones, what types were observed, etc, so we can expedite the normal warm-up and recompilation process This involves attaching blobs of "stuff the JS engine wants back next time" to network cache entries and a whole new path from path from Necko through Gecko to SpiderMonkey, so it's not exactly a small project :) We've actually done some initial work in this direction (motivated by b2g app performance): https://bugzilla.mozilla.org/show_bug.cgi?id=900784 but it seems to be on hold atm. I hope it resumes before long. Cheers, Luke ----- Original Message ----- > Since the html pages are already cached, why not also cache the JIT > compiled javascript while leaving a page? Shouldn't use too much space > than the text content of the embedding page. Much less space than the > image files embedded in a page. > > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
