Compression of the JavaScript Startup Bytecode Cache (JSBC)

[goodusername123]

browser.cache.jsbc_compression_level was added in Firefox 102 with 1757833

This pref is defaulted to 0 which means "disabled"/"no compression" however I propose it should be set to something like a value of 2 or 3 (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:

• Less data being read and written to/from disk.
• Less total disk cache size being used up making room for other things in the disk cache.
• Faster IPC (communication between processes) transfer times for the JSBC, although in Mozilla's testing the compression and decompression times ended up outweighing the improved IPC transfer times.

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):

1. Change browser.cache.jsbc_compression_level to a desired value.
2. Restart browser (? unsure if this is actually required).
3. Visit a website where JavaScript is executed such as Octane 2.0 (might need to press the start button at least once on Octane?).
4. Visit the same website around 5 or more times to activate the JSBC system (reloading the tab doesn't work you need to create new tabs).
5. Visit 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).
6. clear/delete the disk cache ("cache2" folder) and repeat steps 1 through 5 to measure disk space saved with browser.cache.jsbc_compression_level.

Of course this pref would only affect things if browser.cache.disk.enable is set to TRUE however in cases where that is how things are then browser.cache.jsbc_compression_level could make quite a positive impact especially with large JS libaries on frequently visited sites.

[yokoffing]

Thank you for the thorough explanation! This is valuable.

about:cache?storage=disk provides odd Alternative Data size when doing this. With browser.cache.jsbc_compression_level at 3, some values in the right column Alternative Data size is bigger than the left column Data size. Is that correct?

[yokoffing]

Looks like there's also the prefs to alter when bytecode is saved, in case you'd like to test page load times with dom.script_loader.bytecode_cache.strategy at -1. You could also switch to -1 temporarily to do faster testing.

// 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

[goodusername123]

Thank you for the thorough explanation! This is valuable.

about:cache?storage=disk provides odd Alternative Data size when doing this. With browser.cache.jsbc_compression_level at 3, some values in the right column Alternative Data size is bigger than the left column Data size. Is that correct?

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 browser.cache.jsbc_compression_level only affects the Alternative Data size.

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/

[yokoffing]

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

Ahh. Okay. Thank you for the clarification.

For my quick test, based on the Alternative Data size column:

box2d.js 757,914 bytes no compression
box2d.js 234,034 bytes level 2
box2d.js 228,689 bytes level 3
box2d.js 202,330 bytes level 7

Pretty cool.

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 browser.cache.jsbc_compression_level only affects the Alternative Data size.

I see now.