3 ms·
Interesting that while the arch linux the package weighs in a 7MB, it extracts to 80MB installed, and the `difft` binary is a whole 78MB. On a ZFS dataset with
by dsp_person 3y ago
Interesting that while the arch linux the package weighs in a 7MB, it extracts to 80MB installed, and the `difft` binary is a whole 78MB. On a ZFS dataset with LZ4 compression du says it's 17MB. I wonder why not just compress whatever is so compressible in the binary? It would probably even load faster to decompress it in ram.
- speed_spread 3y agoIts probably related to the comment here about the Nim parser being an unmergable 60mb C file. It looks like TreeSitter requires lots and lots of code, a lot of which must be redundant / compressible.
- frankjr 3y agoJust a data point because you mentioned compression and I got curious - it's about 10MB on btrfs with zstd:1. Processed 1 file, 614 regular extents (614 refs), 0 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 14% 10M 77M 77M none 100% 1.1M 1.1M 1.1M zstd 12% 9.8M 76M 76M
- dsp_person 3y agoApparently ZFS 2.2.0 added an early abort capability for zstd compression. Maybe I'll switch over to it.
- dark-star 3y ago> It would probably even load faster to decompress it in ram. An executable is not loaded into RAM completely and then started. It's memory mapped and only the parts that actually get used are loaded (when they are needed). This is why large binaries get slower when you compress them, because then the demand-paging doesn't work anymore I did the test with a 280mb Windows EXE some years ago, compressed down to like 70 megs or so but took multiple seconds longer to start up than the original For some scenarios might make sense (running binaries across the network maybe) but in most cases an uncompressed binary will start up faster