Die beste Kompression!

Als ich wieder mal Langeweile hatte und den Portable TeXmaker aktualisiert habe, hab ich mich wieder einmal mit Kompressionen beschäftigt und welche dann wirklich die beste sei? Ich hab mir einfach gedacht: „Du hast Zeit, langeweile und nen Artikel wäre auch mal wieder fällig.“ Gesagt getan und ca. eine Woche lang verschiedene Varianten ausprobiert. Natürlich habe ich nur eine geringe Auswahl an Programmen ausgewählt, aber hier sind einmal die Testkandidaten:

• 7zip 9.2 (x64)
• uharc06b (x32)
• FreeArc 0.666 (x32)
• nanozip 0.09a (x64)
• PAQ8pxd v5 (x32)
• WinRK 3.12 (x64)

Da ich ja den Portable TeXmaker vor mir hatte, wollte ich diesen möglichst klein verpacken. Auch wenn das Tage dauern würde. Im Endeffekt geht es darum, zu schauen, was alles mit verrückten Algorithmen so geht.
Insgesamt müssen 17982 Dateien mit einer Gesamtgröße von 707.626.496 Bytes verpackt werden. Das sind ca. 674 MB.

7zip

Zuerst habe ich mir 7zip vorgenommen. Ansich habe ich die „Ultra“ Einstellung genommen. Dazu der „LZMA2“ Algorithmus mit einer Wörterbuchgröße von 192 MB, einer Wortgröße von 96 und 8 CPU-Threads.
So hat es 7zip geschafft die 707.626.496 Bytes auf 236.352.275 Bytes zu verpacken. Dies entspricht einem Kompressionsfaktor von 33,4007%. Also fast ein Drittel! Doch da man bei 7zip so viele Sachen einstellen kann, wollen wir einmal schauen welche Auswirkungen die einzelnen Optionen auf die Kompression haben.

Der erste Punkt ist die Wortgröße. Kurz gesagt hier hilft nur ausprobieren, welche Wortgröße das Optimum bringt. im Einzelnen sind es nur ein paar KB. Früher/DAMALS konnte einige KiloByte weniger ein paar Minuten ausmachen :D. Nun ja ich habe die Wortgröße im 2. Versuch auf 128 erhöht. Dabei ergab sich ein Kompressionsfaktor von 33,3996%.

Als nächstes analysieren wir den Faktor der Wörterbuchgröße. Hier habe ich das Wörterbuch auf 256MB erhöht. Der neue Kompressionsfaktor liegt bei Wahnsinnigen 33,3965%!!! Wieder ein paar KB weniger.

Und zum krönenden Abschluss. Der Threadfaktor! Ich setze hier den Wert auf 1 Thread. Nun dauert die Kompremierung zwar länger, aber die paar Minuten mehr stören auch nicht. In der Zeit kann ich erstmal Pizza bestellen :D. Nach dem ich also Pizza bestellt habe, lag nun der Kompressionsfaktor von 33,2558% vor.
Somit habe ich eine Differenz des Komprissionsfaktor von 0,1449 ;D

Hier ist noch mal die Übersicht in Tabellenform mit meinen Testdaten:

Kompression	Verfahren	Wörterbuchgröße	Wortgröße	Threads	Komprimierte Datei (Bytes)	Faktor
Ultra	LZMA2	192MB	96	8	236.352.275	33,4007%
Ultra	LZMA2	192MB	128	8	236.344.573	33,3996%
Ultra	LZMA2	192MB	273	8	236.347.357	33,4000%
Ultra	LZMA2	256MB	128	8	236.323.012	33,3966%
Ultra	LZMA2	256MB	273	8	236.338.813	33,3988%
Ultra	LZMA2	256MB	128	1	235.326.929	33,2558%

 uharc

Irgendwo dachte ich mal gelesen zu haben, dass uharc auch eine super gute Kompression hat. Also habe ich mir die aktuellste Version heruntergeladen. Zur Ernüchterung musste ich feststellen, dass es kaum Einstellungsmöglichkeiten hat. Lediglich eine Wörterbuchgröße war eine erwähnenswerte Einstellung und das Wörterbuch konnte maximal 32MB groß sein. Also habe ich die besten Einstellungen gewählt, inklusive größtes Wörterbuch. Und der Faktor ist … [Trommelwirbel] … 34,5323% :/
Das war dann wohl nichts mit „uahrc“. Schlechter als 7zip. Gehen wir lieber schnell zum nächsten Kandidaten

FreeArc

Bei FreeArc habe ich zuerst nur die Maximale Einstellung genommen. Diese ist standardmäßig bei „-mx -ld1600“. Das Ergebnis kann sich zumindestens mehr sehen lassen, als unser vorheriges Ergebnis: 33,4634%! Naja fast so gut wie 7zip. Aber jedes Byte zählt in meinem Test :P
Da die Einstellung bei Maximum „-mx -ld1600“ ist, wollte ich mal ein paar mehr Infos zu den Einstellungen bekommen. Mit F1 wird man direkt zur Hilfedatei, die in dem Programm hinterlegt ist, weitergeleitet. Nach ein paar Zeilen hab ich doch gleich noch eine bessere Einstellung entdeckt. „-m9x“ bzw. „-mx9“ soll noch eine bessere Kompression haben. Gesagt, getan und ganze 33,4491%. Immer noch schlechter als 7zip, jedoch ist es wieder eine kleine Verbesserung zur vorherigen Einstellungen. Interessant war dann, das man selber die Anordnung der Files bestimmen kann. Wenn gleichartige Files nacheinander kommen, werden diese eventuell besser komprimiert. Nach ein paar Experimenten mit dieser Funktion, gab es keine merklichen Verbesserungen. „-ds=en“ sortiert beispielsweise die Dateien nach Endungen und dann Namen und Ordner sortiert.
Nun ja, nicht wirklich eine große Verbesserung und 7zip ist immer noch erster. Also auf zu nanozip.

nanozip

Auf Nanozip bin ich durch http://www.maximumcompression.com/index.html aufmerksam geworden. Diese Seite macht auch seit Jahren viele Kompressionstest und stellt die Ergebnisse Online zur Verfügung. Ein Blick lohnt sich auf jedenfall in die Statistiken und diese sind auch sehr interessant.
Die beste Kompressionseinstellung ist „-cc“. Zu dem kann man selber bestimmen wie viel Speicher benutzt werden soll. Ich habe ersteinmal generell auf „-m12g“, also 12GB Arbeitsspeicher zur Verfügung gestellt.
Das Ergebnis kann sich mehr als sehen lassen. Ein Kompressionsfaktor von 31,3422% ist schon echt gut. Auch bei nanozip habe ich mir noch andere Einstellungen und Auswirkungen angeschaut. Wie bei 7zip, habe ich bei nanozip paralle Threads laufen lassen und mit mehr und weniger Arbeitsspeicher gearbeitet. Hier die Ergebnisse zusammengefasst:

Kompression-Einstellung	Arbeitsspeicher	Anzahl CPU-Threads	Komprimierte Datei (Bytes)	Kompressionsfaktor
-cc	-m12g	-p8	231.837.795	32,7627%
-cc	-m15g	-p8	231.832.327	32,7620%
-cc	-m12g	-p4	224.748.933	31,7610%
-cc	-m12g	-p2	222.738.703	31,4769%
-cc	-m12g		221.785.465	31,3422%
-cc	-m14g		221.782.424	31,3417%

Damit liegt jetzt eindeutig nanozip vorne. Alle bis hier hin gezeigten Programme, waren im weitesten Sinne auch sehr schnell mit dem Verpacken. Die anderen Tools können schon mal Tage brauchen mit dem Ent- und verpacken :)

PAQ

Bei PAQ gibt es nur eine Einstellung und zwar die der Kompression. „-8“ ist die stärkste Kompression und benötigt auch dementsprechend massig Zeit zum verpacken. Insgesamt hat es 89507.90 Sekunden gedauert. Ein Tag hat 86400 Sekunden, also hat es über einen Tag lang gedauert, bis die Dateien gepackt sind!!! Aber die Arbeit hat sich in jedem Falle gelohnt ;) Mit 216.672.995 Bytes und einem Kompressionsfaktor von 30,6197% ist das noch eine Schippe besser als nanozip. Damit liegt PAQ nun an erste Stelle!

WinRK

Wie nanozip kenn ich auch WinRK von http://www.maximumcompression.com/index.html. Jedoch ist dies ein kommerzielles Programm, deswegen wäre das schon einmal ein großer Minuspunkt. Jedoch soll es auch fast so gut wie PAQ sein, also habe ich mir die Trial-Version heruntergeladen und mal geschaut. Nach ca. 16h Laufzeit hatte ich dann nun das letzte Ergebnis vorliegen: 218.075.937 Bytes! Das ist ein Kompressionsfaktor von 30,8179%. Fast genauso gut wie PAQ, jedoch knapp dahinter.

Fazit

7zip ist ein superschneller und ein sehr gutes Archivierungsprogramm. nanozip kann da sogar zum Teil echt sehr gut mithalten und man spart sogar noch ein paar MB seines Telekom-Volumen. Von WinRK und PAQ würde ich abraten, da diese enorm lange brauchen, damit unser Programm gepackt bzw. entpackt ist.
Aber was haben wir noch gelernt. In Archivierungsprogrammen können gerne Paralle Prozesse integriert werden, jedoch erreicht man dadurch nie das Optimum an Kompression. Außerdem sollte man so viel RAM zur Verfügung stellen, wie es nur geht. Vor allem bei größeren Speichermengen die Verarbeitet werden sollen, lohnt sich diese Einstellung immer.

Soviel von mir, bis demnächst
TheVamp

PS: Der Artikel strotzt bestimmt so vor Rechtschreibfehlern, wer welche findet, darf mir diese gerne in die Kommentare schreiben ^.^