Online Kompression verbessern

[todesstern]

Zitat von Ash

Hallo

Ich würde gerne mal wissen, warum Emule intern eine Zlib Kompression verwendet und keine 7z(open source) die doch eindeutig allen anderen Zipformaten überlegen ist?

Ein Dankeschön für deinen Tipp

Ich bin kein Emule Programierer, dafür gelegendlich ein Datei Releaser. 7z kannte ich bisher noch nicht...hab es also gleich mal getestet.

Bei einer 227 MB großen DivX AVI schaft

Winzip 8.1 = 222 MB
Winrar 3.0 = 221 MB
7Z = 219 MB

(alle drei Packer wurden auf Max Kompression eingestellt)

[Ash]

Zitat von todesstern

Ein Dankeschön für deinen Tipp

Ich bin kein Emule Programierer, dafür gelegendlich ein Datei Releaser. 7z kannte ich bisher noch nicht...hab es also gleich mal getestet.

Bei einer 227 MB großen DivX AVI schaft

Winzip 8.1 = 222 MB
Winrar 3.0 = 221 MB
7Z = 219 MB

(alle drei Packer wurden auf Max Kompression eingestellt)

Es gibt auch noch ein, Uharc Packer v0.4 mit Gui der scheint auch ziemlich gut zu sein.

[Tonixic]

he leute das ist wirklich eine diskusion wert

macht weiter

mir währe lieber das die von euch genanten Pakete (10 * 180KB = 1,75MB) etwas verkleinert werden so auf ungefähr (4 * 180KB = 720KB) oder noch besser währe das mit den gegebenen verbindungsgeschwindigkeiten wariabel zu berechnen z.B. bei 56K nur (1 * 180KB = 180KB) und oder 128K (4 * 180KB = 720KB) oder und bei 768 [oder schneller] (10 * 180KB = 1800KB) dan wüden die Wartezeiten "vor allen"am anfang nicht so stark vareiren.

übrigens ich hab nicht den hauch einer ahnung was Programmierung oder Komprimierung angeht ich hab jetzt einfach nur meine Ideen ins Spiel gebracht.

ciao Tonixic

[/dev/NULL]

Zu Ashs Vorschlag: Die Idee fände ich gut, mehr Kompression = mehr DL in der gleichen Zeit.
Die Kompression als zusätzliches Feature einzubauen (für Clients die das können) ist denke ich auch ok, es muß sich halt nur mal ein Modder dazu entschliessen, die zLib (normale Zip Kompression) geht ja nicht verloren, die kann 7z ja auch.
--> Verlieren kann man meiner Meinung nach nichts außer am Anfang einer Session ein paar Packets um das Kompressionsformat festzulegen (ala: ich biete dir an 7z zip oder unkomprimiert, wähle dein Schicksal!)

Zu Ashs weiterer Idee: man kann IMHO schlecht On the Fly komprimieren, da die endgültige Datei (das komprimierte Ding) erst nach der Komprimierung feststeht, also nix mit wir komprimieren so schnell wie wir senden.. wir können erst senden, wenn alles fertig gepackt ist.

Sourcen gibts bei SourceForge.

Ein kurzes googlen nach Vergleichstest sagt mir: 7z packt im schnitt um 10% besser als Winzip (Textdokumente deutlich besser, aber wer tauscht .txt?), ist aber um den Factor 8 langsamer als zip.

Allerdings sollte man bedenken das es mittlerweile ne 3.09 beta gibt und die womöglich etwas schneller ist als die alte.

edit: ab beta 3 unterstützt er auch HT, was vielleicht einigen zu neuen boosts verhilft..

Meine Meinung: kleine Blocks behalten und 7z wäre für mich völlig ok, wenn ich dann vor jedem verschickten Block 0.3 Secs warten muß.. na und? ich hab die CPU Power..

Nachlesen:
http://www.rojakpot.com/showarticle.aspx?artno=4&pgno=1
andere Tests:
http://compression.graphicon.ru/ybs/e&exes.htm
http://www.compression.ca/act-win.html

[Ash]

7-zip ist ja auch nur eine Gui für verschiedene Algorytmen "LZ+Huf" noch etwas besser wäre vielleicht eine "f+PPMII" Routine, wie sie der neue DURILCA Packer benutzt, auch wenn die noch etwas mehr CPU Power brauch.

Jedenfalls ist alles besser als wie der jetzige Algorithmus! Die Rechner von heute haben doch mit nix mehr ein Problem! Für die Kleckerei mit ein paar Prozentchen CPU Power pflegt man doch keine Dinosaurier.

Nur leider basteln ja alle nur drum rum, an echte Veränderungen im Kern denkt garkeiner!

etwas aktueller:
http://www.maximumcompression.com/