1768255 - Find conditions when JSBC compression improves page load time

Status: NEW

(Core :: JavaScript Engine, enhancement, P2)

Description

[Bryan Thrall [:bthrall]]

Compressing the JavaScript bytecode that is stored in the JS Bytecode Cache has the benefit of reducing IPC and disk I/O time, but at the cost of taking time to do the compression and decompression.

We should explore which conditions make compressing the bytecode more efficient than not compressing at all. Specifically, when do shorter IPC and disk I/O times outweigh the extra time taken to compress the bytecode?

Conditions that are worth exploring include:

• Does larger bytecode size make a difference?
• Which compression algorithm should we use?
• Are there compression parameters we should consider?

Comment 1

[Mayank Bansal]

Maybe things will improve with zstd, which has a much faster decompression time?
ZSTD is not generally availablie in gecko. See Bug 1947431 and co

Comment 2

[Tooru Fujisawa [:arai]]

Once the stencil navigation is enabled, the serialized stencil is decoded only once per single content process, as long as the cache is valid,
and the remaining pageload will use the in-memory raw stencil cache.
And also the encoding/compression is done off main thread with possibly more flexible scheduling.

Given the above, this bug can be re-purposed to focus more into reducing the disk space consumption.

According to bug 1757833 comment #15, the disk cache size can be reduced by 60% with zlib compression level 2.
As long as the decompression doesn't take too long time, we can enable it.

If the decompression performance regresses the loadtime, we could look into other compression algorithm with:

• good compression ratio
• decoding isn't costly
• encoding can take some time

and https://github.com/facebook/zstd shows that zstd has better performance on the decompression, especially with the "fast" mode.