Garten
Eden

Das klassische ZIP? Oder lieber tar-gepackt in Kombination mit bzip2 oder gzip? Oder doch lieber modern mit 7zip? Diese Frage stellte ich mir jedes Mal, wenn ich Nautilus’ Kontextmenü-Eintrag zum Komprimieren von Daten nutzte. Warum also nicht ein pseudo-wissenschaftlicher, empirischer Test?

Welche Formate testen wir?

Dieser Vergleichstest soll weder eine detaillierte Studie werden noch soll sie möglichst viele Kompressionsalgorithmen testen. Ich habe mich bei meiner Auswahl dazu entschlossen nur eine Hand voll Komprimierungsverfahren zu prüfen und auch nur diejenigen, die bei der Ubuntu-Standardinstallation dabei sind. Eine Ausnahme bildet 7zip. Da seine Kompressionsstärke überall gefeiert wird und eine Nachinstallation in Ubuntu kinderleicht ist (empfohlenes Paket: p7zip-full), hat es dieser Algorithmus auch in die Auswahl geschafft. Es treten also gegeneinander an:

• 7z 9.04 beta
• bzip2 1.05
• gzip 1.3.12
• ZIP 3.0

Ich denke, die Begründung für bzip2 und gzip sind einleuchtend; es gibt kaum andere Formate, die in der Unix-Welt häufiger vorkommen. ZIP hingegen wird von vielen als Quasi-Standard angesehen – Wir überprüfen, ob diese Annahme berechtigt ist.
Man könnte sich nun fragen, warum nicht mehr Formate aufgenommen wurden. Nun, mir war wichtig, gängige Algorithmen zu nehmen und nicht exotische, die auf den meisten Systemen Probleme verursachen. Meiner Meinung nach ist bei komprimierten Daten wichtig, dass sie fast so leicht wie nicht-komprimierte zu handhaben sind. Die Mühe lohnt häufig nicht, wenn die Zeit-/Volumenersparnis beim Empfänger des Archivs durch eine nötige Nachinstallation zunichte gemacht wird.

Welche Einstellungen?

Ähnlich sieht die Begründung für die vorgenommenen Einstellungen aus. Ich verwende für alle Tools die Standardeinstellungen. Das sind auch genau die, die das Ubuntu-Programm file-roller anwendet. Das hat den Vorteil, dass nur ein Rechtsklick auf die Datei(en) und einer auf Komprimieren… notwendig ist, um ein verkleinertes Archiv zu erhalten. Ich vermute, dass das die häufigste Variante des Komprimierens bei Ubuntu-Nutzern ist.
Um es einmal deutlich zu sagen: Es geht nicht darum, für jedes Verfahren die optimalen Optionen zu verwenden und diese dann miteinander zu vergleichen. Ich behaupte, dass die Standardeinstellungen schon hinreichend vernünftig sind und dass sich vor allem der Normalbenutzer selten die Mühe macht, die passende Konfiguration zu suchen, sondern eben die vorgegebenen Werte nimmt. Natürlich bleibt es weiterhin jedem selbst überlassen, sein Lieblingstool so zu verwenden, wie es ihm/ihr behagt.

Welche Daten?

Als zu komprimierenden Datensatz habe ich mich für ein Quellcode-Paket von Firefox entschieden. Dieses Paket enthält neben Bildern vor allem ASCII-Dateien, mit denen sich die Algorithmen austoben können, um ihre Stärken und Schwächen offenzulegen. Außerdem halte ich diese Daten auch für alltagstauglich. Das belegen auch einige anschließenden Nachtests, die ähnliche Ergebnisse lieferten wie mit diesem Paket. Direkt zu beziehen ist die Datei von dem Mozilla-FTP-Server.

Die Testumgebung

Dieser Benchmark wurde auf einem mobilen Computer mit Intel Core 2 Duo P8400-Prozessor (2,26 Ghz) auf einer tmpfs-Partition ausgeführt. Eine solche RAM-Partition liest und speichert Dateien nicht auf einer Festplatte, sondern dem Arbeitsspeicher. Somit konnte ich langsame Schreiboperationen vermeiden. Das Betriebssystem ist Ubuntu 10.10 Maverick mit Ubuntu-Kernel 2.6.35-24-generic.

Die Methode

Zum Hauptthema, dem Vergleich der einzelnen Verfahren. Untersucht wurden zwei Eigenschaften: die benötigte Zeit zum Packen der Dateien (Geschwindigkeit) und die letztendliche Größe des entstandenen Archivs (Kompressionsgrad). Wie gesagt, um das Ubuntu-Standardverfahren zu erhalten, wurde file-roller aufgerufen. Die Dauer wurde (nach Anlaufschwierigkeiten) mit time ermittelt. Um leichte Schwankungen auszugleichen, muss jeder Algorithmus fünfmal ran. Diese Arbeit erledigt ein selbstgeschriebenes Bash-Script für mich.

#!/bin/bash 
#analyze time needed to compress data with several compression algorithms 
#using file-roller and time 
 
ARCHIVES='7z tar.bz2 tar.gz zip' 
INPUT='data/' 
MAXITER=5 
TIMEOPTS='-a -o stat -f "%C\t%e"' 
 
for (( I=1; $I <= $MAXITER; I++ )) 
do 
	for TYPE in $ARCHIVES; do 
		echo "Round #$I compressing $TYPE..."
		/usr/bin/time $TIMEOPTS file-roller -a archive$I.$TYPE $INPUT 
	done 
	echo '---' 
done

Die Variable $ARCHIVES enthält die zu nutzenden Algorithmen, $INPUT die Quelldaten, während $MAXITER die Anzahl an Durchgängen bestimmt und $TIMEOPTS die Optionen für time festlegt. In meinem Fall wird hier die Zeitmessung in eine Datei stat geschrieben und fortlaufend ergänzt (-a) und zwar in meinem bestimmten Format, bestehend aus dem ausgeführten Befehl, einem Tabulator und der effektiven Zeit. (Sämtliche Formatierungen finden sich in der man-page von time.)

So viel zur Geschwindigkeit. Der zweite Aspekt, der Kompressionsgrad, wurde anschließend mit

ls -l

bestimmt.

Das Ergebnis

Kommen wir nun endlich zum Ergebnis des Tests.

Damit lassen sich folgende Schlüsse aus den Daten ziehen:

• 7z bietet die beste Leistung, dauert aber auch am längsten.
• ZIP lohnt sich nicht. gz ist deutlich schneller und komprimiert besser.
• bz2 erweist sich als schlechter Kompromiss aus 7z und gz, denn je nach Geschwindigkeits- oder Leistungspräferenz bieten sich eher die Konkurrenten an.

Persönliche Einschätzung

Ich muss sagen, für mich brachte der Test neue Erkenntnisse. Während ich bisher Dateien häufig mit bz2 komprimierte, werde ich jetzt wohl so oft wie möglich auf gz vertrauen, weil es die Daten schon recht effizient stauchen kann. Nur in den Fällen, wo eine möglichst starke Kompression vonnöten ist, wird 7z weiterhin mein Favorit bleiben. Zu ZIP bleibt dann nicht mehr viel zu sagen, nur, dass ich hoffe, diesen Quasi-Standard (ähnlich MP3) langsam aber sicher vom digitalen Spielfeld/aus dem Internet verschwinden zu sehen.

Eine kleine Anmerkung zu gz: Als einziges der getesteten Verfahren ist gz nicht „md5sum-sicher“, d. h. allein anhand eines veränderten MD5-Hashes lässt sich nicht darauf schließen, ob die Daten im Archiv verändert wurden oder identisch sind.

Download

Hier gibt es die Rohdaten und das Bash-Script zum Download.
↶ compresstest.sh (399B text/x-shellscript) oder
↶ compresstest.sh.gz (319B application/x-gzip)
↶ comprtest_output.txt (1,4KB text/plain) oder
↶ comprtest_output.txt.gz (321B application/x-gzip)

Nachtrag

→ Beachten Sie auch den anschließenden Kurztest des vielversprechenden Kompresssionsverfahrens LZO.

Update am 06.01.2011 13:50