Hacker News Reader

Comment by dsp_person | Hacker News Reader

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.

View on HN

Just 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

Apparently ZFS 2.2.0 added an early abort capability for zstd compression. Maybe I'll switch over to it.

Its 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.

> 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

Reply on news.ycombinator.com