Neulich laß ich von einer neuen BZ Generation: BZIP3 . da war klar, daß man das mal ausprobieren müßte 🙂

BZIP3 ist der klare Gewinner

Wir haben einen Rechner mit 2 Kernen ( um BZIP3 nicht zu übervorteilen ) und dieses File:

bugreport-catalina.log 754.294.618 Bytes

In der Datei sind sehr sehr viele redundante Daten drin, weil das ein Tomcat Log ist, das im Zuge einer Buganalyse angefertigt wurde. Natürlich soll Bzip3 ruhig beweisen, daß es mit vielen Kernen gleichzeitig rechnen kann, also starten wir die Uhr und geben Bzip3 die zwei Kerne zur Seite:

# time bzip3 -f -j 2 bugreport-catalina.log

real 0m5,894s
user 0m10,594s
sys 0m0,203s

700MB sind in 5.893s Sekunden super. Im Userspace ist es doppelt solange, weil 2 Prozesse liefen!

Jetzt das ganze für xz, was per se nicht schlecht packt und auch schnell sein muß, weil es in Repos zum Packen von Daten benutzt wird. Da das echt viele Pakete sind die man da packt, würde ein wirklich langsamer Algorithmus viel Schaden anrichten 😉

# time xz bugreport-catalina.log

real 1m36,899s
user 1m33,361s
sys 0m0,508s

Wow.. das ist mal sowas von langsam im Gegensatz zu Bzip3, daß es jetzt ja mindestens besser packen müßte, oder? Schau wir mal, was raus kam:

bugreport-catalina.log.bz3 2.601.886 Bytes
bugreport-catalina.log.xz 12.100.520 Bytes

Das war’s dann wohl mit xz as Packer 😀 Danke für die tolle Arbeit, aber jetzt ist Zeit für den digitalen Ruhestand. Leg Dich schlafen xz, Du bist obsolete 😀

Nachtrag:

Jetzt xz mit 2 Kernen und extrem guter Kompression… Zeitlich war das nicht zu unterbieten was Bzip3 vorgelegt hat. „-k => KEEP original -T 0 => alle kerne die gehen -e EXTREME“

# time xz -T 0 -e -k bugreport-catalina.log

Weiter kam man nicht, weil das nach mehr als 14 Minuten immer noch am laufen war, ohne Aussicht auf Erfolg.

Fazit: OBSOLETE