Compress v8 snapshot files within the apk (265kb) |
|||||||
Issue descriptionWe store snapshot_blob_32.bin and natives_blob.bin uncompressed within the apk so that they can be mmap'ed by v8. V8 doesn't really need random access to the files though (they contain serialized data). v8 bug: v8/8720 UPDATE! These are old numbers. Refer to comment #6. Looking at snapshot_blob_32.bin, it actually compresses quite well: -rw-r--r-- 1 agrieve primarygroup 240K Jan 1 2001 snapshot_blob_32.bin.bro -rw-r--r-- 1 agrieve primarygroup 325K Jan 1 2001 snapshot_blob_32.bin.liz2 -rw-r----- 1 agrieve primarygroup 384K Apr 16 06:54 snapshot_blob_32.bin.gz -rw-r--r-- 1 agrieve primarygroup 432K Jan 1 2001 snapshot_blob_32.bin.lz -rw-r--r-- 1 agrieve primarygroup 433K Jan 1 2001 snapshot_blob_32.bin.liz -rw-r--r-- 1 agrieve primarygroup 1.4M Jan 1 2001 snapshot_blob_32.bin -rw-r--r-- 1 agrieve primarygroup 176K Jan 1 2001 natives_blob.bin -rw-r--r-- 1 agrieve primarygroup 33K Jan 1 2001 natives_blob.bin.bro -rw-r--r-- 1 agrieve primarygroup 46K Jan 1 2001 natives_blob.bin.liz2 The .liz files were compressed with: https://github.com/inikep/lizard at -19 and -29 for .liz and .liz2 respectively. The .lz was with "lz4 -12" brotli decompresses faster than gz. .liz / .lz are 5-6x faster than that. brotli is already a part of Chrome, but lz4 / lizard are super tiny additions. We'd probably want to see if brotli is "fast enough" on a low-end device, and if not, use lz4 / lizard. Likely best way to figure this out is to instrument the snapshot-loading code. We could also consider compressing the file as part of it's .zip entry. That way it would participate better in patch updates.
,
Aug 1
,
Oct 24
Since filing the bug, embedded builtins has moved a lot of the code from the snapshots into the .so file. As of M71, the snapshot files are 413kb combined: https://storage.googleapis.com/chrome-supersize/viewer.html?load_url=milestones%2Farm%2FMonochrome.apk%2Freport_71.0.3574.0.ndjson&include=blob.*bin&exclude=assets%2Funwind_cfi Updating expected savings assuming same compression ratio (of 74%)
,
Oct 24
,
Oct 24
,
Yesterday
(44 hours ago)
Now as of M73: snapshot_blob.bin: 277kb natives_blob.bin: 81kb Estimated savings = 358 - (358*.26) = 265kb
,
Yesterday
(44 hours ago)
Note: This still seems quite worth it to me!
,
Yesterday
(44 hours ago)
I don't think the compression ratio would stay the same. Previously the snapshot contained mostly native machine code. This is no longer the case, as we moved these machine code into the binary. The rest are serialized V8 objects.
,
Yesterday
(43 hours ago)
,
Yesterday
(42 hours ago)
Just re-checked. Looks like they actually compress a tiny bit better now: $ zip asdf.zip * adding: natives_blob.bin (deflated 84%) adding: snapshot_blob_32.bin (deflated 77%) $ ll total 444K -rw-r----- 1 agrieve primarygroup 78K Jan 21 13:20 asdf.zip -rw-r--r-- 1 agrieve primarygroup 81K Jan 1 2001 natives_blob.bin -rw-r--r-- 1 agrieve primarygroup 278K Jan 1 2001 snapshot_blob_32.bin -rw-r--r-- 1 agrieve primarygroup 12K Jan 1 2001 natives_blob.bin.bro -rw-r--r-- 1 agrieve primarygroup 50K Jan 1 2001 snapshot_blob_32.bin.bro |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by jgruber@chromium.org
, Apr 16 2018