Nicolas, when JSBC is enabled by default, should we change our test
procedure for our various page load tests (Talos and Softvision's manual
testing)? Since the first page load will be slower than subsequent page
loads (as you noted in the bug [1]), should we throw away the first page
load time or continue to average it with the subsequent page load times?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72
chris
On 6/13/17 2:50 AM, Nicolas B. Pierron wrote:
The JavaScript Start-up Bytecode Cache⁰ is a project which aims at
reducing the page load time by recording the bytecode generated during
the last visits and by-pass the JavaScript parser.
This project changes the way we process JavaScript script tags which are
fetched from the network, and cached. After multiple visits¹, the
bytecode would be encoded incrementally², as soon as the bytecode
emitter generates it. Once we reached some idle time³, we save the
content encoded incrementally as an alternate data on the cache⁴. The
cache contains a compressed version of the source, the bytecode of
functions which got executed during the start-up of the page, and all
non-executed functions encoded as source indexes⁵.
On follow-up visits the script loader would load the alternate data
instead⁶ of the source, and decode the bytecode either off-thread⁷ or on
the current-thread. This is expected to replace the syntax checker and
the bytecode emitter for all recorded functions.
This feature is currently pref-ed off and can be enabled by setting the
following preferences in about:config⁸:
- dom.script_loader.bytecode_cache.enabled = true
- dom.script_loader.bytecode_cache.strategy = 0
For any issue caused by this optimization, filed it as a blocker of Bug
900784.
In the upcoming days, I will add telemetry probes to better tune the
heuristics¹ for the web and monitor the known sources of fallback and
failures. In addition, I will request for a pref-experiment, such that
we can get more data from nightly users. At the moment, I expect to
enable this feature around mid-July.
⁰ https://bugzilla.mozilla.org/show_bug.cgi?id=900784
¹ These are heuristics which would be customized by running a
pref-experiment. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1362114)
² We cannot do it off-thread, nor after the execution (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1316081)
³ Currently set to the next cycle after the processing of the OnLoad
event. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1372207)
⁴ Thanks to Valentin Gosu for his work and support on the alternate data
interface as part of necko. (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1231565)
⁵ https://bugzilla.mozilla.org/show_bug.cgi?id=917996
⁶ This forces us to store the compressed source as part of the encoded
bytecode, but prevent additional round-trip between the parent and child
processes.
⁷ https://bugzilla.mozilla.org/show_bug.cgi?id=1316078
⁸
http://searchfox.org/mozilla-central/rev/d840ebd5858a61dbc1622487c1fab74ecf235e03/modules/libpref/init/all.js#212-233
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
