-
-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compression of the JavaScript Startup Bytecode Cache (JSBC) #247
Comments
Thank you for the thorough explanation! This is valuable.
|
Looks like there's also the prefs to alter when bytecode is saved, in case you'd like to test page load times with // PREF: strategy to use for when the bytecode should be encoded and saved
// [1] https://searchfox.org/mozilla-release/source/modules/libpref/init/StaticPrefList.yaml#3461-3488
// -1 = saved as soon as the script is seen for the first time, independently of the size or last access time
// 0 = saved in order to minimize the page-load time (default)
//user_pref("dom.script_loader.bytecode_cache.enabled", true); // DEFAULT
//user_pref("dom.script_loader.bytecode_cache.strategy", 0); // DEFAULT |
The Data size column shows/holds the unprocessed file as it was cached/downloaded from the URL/server while the Alternative Data size column shows/holds a version of the file that was processed by Firefox in some way to reduce the amount of work needed to use it again so in the case of .js files the Alternative Data size column has a version of the .js file that was parsed and converted to bytecode which is why the sizes are different, And More information about both the JSBC system which caches compiled JavaScript bytecode and the Alternative Data system/column are available at this link: https://blog.mozilla.org/javascript/2017/12/12/javascript-startup-bytecode-cache/ |
Ahh. Okay. Thank you for the clarification. For my quick test, based on the Alternative Data size column:
Pretty cool.
I see now. |
browser.cache.jsbc_compression_level
was added in Firefox 102 with 1757833This pref is defaulted to
0
which means "disabled"/"no compression" however I propose it should be set to something like a value of2
or3
(the pref hooks directly up to zlib compression levels), this pref seems to provide pretty noticeably lower disk cache sizes for JSBC leading to benefits such as:I did some testing of my own with cache sizes on Octane 2.0:
The steps I did for testing are below as follows (I did also confirm the sizes listed where present on disk):
browser.cache.jsbc_compression_level
to a desired value.about:cache?storage=disk
and check under the "Alternative Data size" column for the cached .js files which will list the on disk size of the JSBC for the js in question (if the size is "0 bytes" then that means the file was not processed through into the JSBC).browser.cache.jsbc_compression_level
.Of course this pref would only affect things if
browser.cache.disk.enable
is set toTRUE
however in cases where that is how things are thenbrowser.cache.jsbc_compression_level
could make quite a positive impact especially with large JS libaries on frequently visited sites.The text was updated successfully, but these errors were encountered: