4 ms·

Faster decompression. These things are loaded on every boot, which needs to be fast. That includes both the time to load them into RAM and to decompress them,

by faho 9y ago

Faster decompression. These things are loaded on every boot, which needs to be fast. That includes both the time to load them into RAM and to decompress them, and it's possible that gzip still wins on that. Personally, I keep my initrd uncompressed because I've found that on my SSD loading that is faster than loading any compressed version + decompressing it, but that doesn't hold for spinning rust.

ComputerGuru 9y ago
Sure, but this is the installer presumably being loaded from CD/USB; in addition to not needing to be compressed the same as the resulting installation and being a one-time ordeal, these are slower media: the less you have to read from disk, the faster your end result may be, even including decompression time. It’s why lz4 compression of a file system can be faster than no compression even with an ssd on fast machines; I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)?
- faho 9y ago
  >Sure, but this is the installer presumably being loaded from CD/USB Doesn't have to be. You could also load it from HDD, which is probably rather common when we're talking about containers and such (and in other circumstances, the couple of MB you'd save here with xz hardly matter). Also there's this PXE thing that I don't understand. > I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)? It didn't last time I checked, but it seems like it does now. So I'll give that a go.
  - faho 9y ago
    Turns out it's a wash. On my arch machine the uncompressed image is 27M, with lz4 it's 14M. Both take around 10s to desktop according to `systemd-analyze` (which includes 3s bootloader timeout). Though I did figure out that for some reason my system was running "lvm2-monitor.service", which took 1s all by itself for doing absolutely nothing (don't use lvm). So I masked that and gained more time than any compression method could.
    - ComputerGuru 9y ago
      Thank you very much for sharing those results!

by faho 9y ago

ComputerGuru 9y ago

Sure, but this is the installer presumably being loaded from CD/USB; in addition to not needing to be compressed the same as the resulting installation and being a one-time ordeal, these are slower media: the less you have to read from disk, the faster your end result may be, even including decompression time. It’s why lz4 compression of a file system can be faster than no compression even with an ssd on fast machines; I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)?

faho 9y ago
>Sure, but this is the installer presumably being loaded from CD/USB Doesn't have to be. You could also load it from HDD, which is probably rather common when we're talking about containers and such (and in other circumstances, the couple of MB you'd save here with xz hardly matter). Also there's this PXE thing that I don't understand. > I wonder if that would boost your performance vs the uncompressed image (though I don’t know if the kernel supports lz4 decimal at boot time)? It didn't last time I checked, but it seems like it does now. So I'll give that a go.
- faho 9y ago
  Turns out it's a wash. On my arch machine the uncompressed image is 27M, with lz4 it's 14M. Both take around 10s to desktop according to `systemd-analyze` (which includes 3s bootloader timeout). Though I did figure out that for some reason my system was running "lvm2-monitor.service", which took 1s all by itself for doing absolutely nothing (don't use lvm). So I masked that and gained more time than any compression method could.
  - ComputerGuru 9y ago
    Thank you very much for sharing those results!