The side effect being that other pages will likely load and execute again code which was present in a previous runtime, and in addition, they will load scripts which are uniq to this new page. This implies that the transition time to a panel would be increased as we have to load extra scripts and do extra execution, compare to what used to be done.
The goal is to define a cutting point at which we will start generating "extra data" which contains data using less space than the source and contains the bytecode of all functions used during the start-up (less than 25%) and contains the lazy-scripts of all other functions.
The idea being that we can store "extra data" as large as the source, or less, while reducing the number of operation on the ciritical path of the start-up (checking CSP, checking script validity, generating bindings). This way the source is optional (and thus can be loaded outside the critical path) until we reach the cutting-point or we are explicitly asked for it with toSource.
Most (all?) JSScript used in the applications are compile-and-go applications. We need to instrument XDR, such as we can encode and decode compile-and-go scripts and re-link the bytecode (see Bug 288473 comment 7) to substitute the embedded global.
We can experiment this on sunspider/kraken benchmarks by looking at the effect by implementing a dummy cache as part of the load JS-Shell function to confirm the expected speed-up.
Then we will need to make this work with the ScriptLoader, and add an extra data cache to packaged-app, app-cache and the http-cache (see Bug 900255).
Tracking Bug: Bug 900784
The refactoring of Gaia applications is planned for 1.4. (see Haida roadmap)
- Gaia Roadmaps: https://docs.google.com/spreadsheet/ccc?key=0AmStZDZgJbV7dDhtMDZlQmRtdDB4a1plZXRwNXIzYWc#gid=0
- Haida Roadmap: https://wiki.mozilla.org/FirefoxOS/Haida
- Bug 900255: Support new API for reading/writing "extra" data for cache entries
- Bug 883154: Share scripts amond compartments which are part of the same runtime. This optimization only works within the JS Engine and does not prevent execution of the CSP nor loading the source. Also it does not work for workers which might load the same scripts as the worker has its own runtime.
- Bug 813324: Profile the cost of caching all the bytecode (before the lazy script implementation) on a desktop, and profile what time it takes to load the bytecode compared to loading the source by doing it purely on the JS side. This show that we can save hundreds of milli-seconds on large scripts (of 2.5 MB of bytecode) such as the one provided by drive.google.com on a desktop.
- Bug 679939: Suggest removing COMPILE_N_GO optimization in favor of caching the bytecode. This bug can be worked around during the development of the JS Cache by providing a re-link phase to the XDR Decoder as suggested in Bug 288473 comment 7.
- Bug 288473: Attempt to do a cache implementation for JS and reports that the bytecode saved by XDR has way more overhead than the minified sources.