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… >