Falls jemandem der Titel dieses Post bekannt vorkommen sollte: Das ist Absicht. Ein gewisser [ENC]BladeXP hatte Ende 2016 bereits einen Artikel zu dieser Thematik geschrieben, und ich wollte das Experiment mal auf einem aktuellen System wiederholen. Allerdings mit einer kleinen Ergänzung: Ich habe mir auch die Zeiten für die Dekompression angesehen.

Verwendet wurde hierfür ein System mit einer NVMe SSD, einem Intel Core i7-8550U, sowie 16GB RAM.

Erzeugen der Ramdisk + Kompression

Nach jedem Kernelupdate muss unter Archlinux mit Hilfe des Tools mkinitcpio eine neue Ramdisk erzeugt werden, welche der Kernel zum Booten benötigt.

In der Tabelle befindet sich dafür jeweils die Angabe des Kompressionsalgorithmus, die Größe der Fallback- und der Standard-Ramdisk, sowie die dafür benötigte Zeit. Der Prozentwert setzt lediglich die erzeugte Dateigröße in Relation zu einer unkomprimierten Ramdisk.

Algorithmus Fallback (MB) Standard (MB) Zeit (s) Prozent (%)
cat (none) 127 66 12,9 100,0
gzip 39 22 22,0 31,6
bzip2 37 21 26,6 30,1
lzma 27 15 122,9 21,8
xz 27 15 122,6 21,8
lzop 55 31 13,4 44,6
lz4 58 31 13,4 46,1
zstd 38 21 13,4 30,6

cat (none)
Erzeugung der Ramdisk ohne Kompression. Geht zwar schnell, erzeugt aber auch die größten Dateien. Einziger Nachteil ist der relativ hohe Platzverbrauch.

gzip, bzip2
Die beiden etwas älteren Kompressionsformate erzeugen zwar bereits relativ kleine Dateien, brauchen dafür aber auch grob die doppelte Zeit. Nicht zu empfehlen, zumal die Dekompression relativ langsam ist.

lzma, xz
Sowohl lzma als auch xz erzeugen sehr kleine Dateien, brauchen dafür aber auch gut die zehnfache Zeit. Für gewisse Szenarien mag das Sinn ergeben, hier allerdings nicht.

lzop, lz4, zstd
Die drei Verfahren erzeugen mit kaum wahrnehmbaren Overhead (gerade mal 0,5s im Vergleich zu cat) relativ kleine Dateien, wobei zstd auf eine ähnliche Kompressionsrate wie gzip bzw. bzip2 kommt. Leider ist zstd noch nicht fester Bestandteil des Kernels, und ein Booten einer mit zstd komprimierten Ramdisk daher nicht so einfach möglich. Auch wenn lz4 minimal größere Dateien als lzop erzeugt rate ich zu lz4, da die Dekompressionsgeschwindigkeit (wie man gleich sehen wird) bei lz4 wesentlich höher ist.

Lesen der Ramdisk + Dekompression

Die Dekompressionszeit zu messen war leider nicht ganz so einfach. Letztlich habe ich mich dafür entschieden Werte zu nehmen, die ich aus diversen Quellen zusammengetragen, und einer Plausabilitätsprüfung unterzogen habe. Außerdem ist die Dekompression alleine nicht entscheidend für den Bootvorgang, sondern muss auch in Relation zur Lesegeschwindigkeit des Speichermediums gesehen werden.

In der folgenden Tabelle habe ich meine NVMe SSD als Referenz genommen, welche lesend ca. 1,5GB/s schafft.

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,044 0,044 100,0
gzip 22 0,015 684 0,032 0,047 106,4
bzip2 21 0,014 171 0,123 0,137 310,9
lzma 15 0,010 335 0,045 0,055 124,5
xz 15 0,010 308 0,049 0,059 133,4
lzop 31 0,021 950 0,033 0,053 121,1
lz4 31 0,021 2000 0,016 0,036 82,2
zstd 21 0,014 1600 0,013 0,027 61,6

Wie man sehen kann ist der Lesevorgang plus die Zeit, welche die Dekompression benötigt, nur bei Einsatz von lz4 oder zstd unter der Zeit, die eine unkomprimierte Ramdisk benötigt. Bei sehr schnellen Speichermedien ist es also fraglich, ob man überhaupt eine Kompression anwenden sollte. Der einzige Vorteil sind die reduzierte Anzahl der Schreib-/Lesezyklen auf das Speichermedium, im Bootvorgang selbst macht es aber keinen Unterschied mehr. Zumal wir hier von Zeit im Bereich weniger Millisekunden reden.

Spannender wird es, wenn man ein etwas langsameres Speichermedium verwendet. Als Beispiel eine SATA-3 SSD welche "nur" 500MB/s lesend schafft:

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,132 0,132 100,0
gzip 22 0,044 684 0,089 0,076 57,7
bzip2 21 0,042 171 0,339 0,165 124,9
lzma 15 0,030 335 0,125 0,075 56,6
xz 15 0,030 308 0,136 0,079 59,6
lzop 31 0,062 950 0,091 0,095 71,7
lz4 31 0,062 2000 0,045 0,078 58,7
zstd 21 0,042 1600 0,037 0,055 41,8

Auch hier ist zstd wieder klar führend, gefolgt von lz4 (gzip, lzma und xz fallen aufgrund der geringen Kompressionsgeschwindigkeit bei der Erzeugung weg). Lzo ist auch nicht wirklich schlecht, aber es ist doch ein deutlicher Unterschied gegenüber lz4 erkennbar. Und bzip2 ist für heutige Anwendungsfälle einfach nicht mehr geeignet.

Fazit

Lz4 ist das Mittel der Wahl. Der Algorithmus bietet, unter Berücksichtigung des Speichermediums, der Kompressionszeit/-rate, sowie der Dekompressiongeschwindigkeit, im Moment das beste Verhältnis. Zstd wird wohl der bessere Nachfolger, ist aber zur Zeit noch nicht im Kernel enthalten.

Es bleibt allerdings fraglich, ob bei Speichermedien >500MB/s die Kompression überhaupt noch Sinn ergibt. Die Werte sind jetzt schon kaum mess- geschweige denn wahrnehmbar.