Those milliseconds matter. When you have a thousand processes starting up shaving off a couple fractions of a second on each helps you hit the less than 10 second boot time. On Sun, Feb 21, 2021 at 4:48 AM Archange via arch-general < arch-general@lists.archlinux.org> wrote:
Le 21/02/2021 à 02:56, Geert Hendrickx via arch-general a écrit :
On Sat, Feb 20, 2021 at 21:25:21 +0100, mpan via arch-general wrote:
I benchmarked it on my mkinitcpio image, and zstd with mkinitcpio's […] Though you have benchmarked a wrong thing. It’s decompression time that matters here, not compression. The image is compressed to make it load faster during boot and that’s the important metric here.
Compression time matters also, since on many systems an initramfs gets booted only once or a few times for every time one gets generated, and zstd -19 is ridiculously slow for larger files, However mkinitcpio v30 reverted to zstd's default compression level 3, which is much better.
Excepted that decompression is a blocking event for boot, while compression is async.
Anyway, based on the benchmark published on the PR that reverted to the default level, using -8 seems the best tradeoff for fast compression and small size, and −18 if space really is an issue (or you’re reading the file from a floppy…).
Also, on most systems nowadays we are talking about changes in the order of hundreds of milliseconds, while I take ~5s to type my entire LUKS passphrase on boot. So…