PureBoard

Hallo!

Ich will eure Meinung zu dem in PB verwendetem Komprimeirungsalgorythmus " JCalG1" hören.
Ich weiß, es kommt immer auf eine Datei drauf an, wie gut die sich komprimieren lässt, aber trotzdem starte ich mal diese Diskussion. Übrigens: Ich spreche immer von maximalster Komprimierung, die Zeit ist (fast) egal.

Ich habe ein kleines Zusatztool, "SuperTeam Keybinder 1.5" für "Tactical Ops" mit PB komprimiert. Ergebnis: Von 313 KB auf 60,8 KB.
Mit Winrar sieht das jedoch leicht anders aus: Von 313 KB auf 53,9 KB.
Zum Vergleich ZIP: 62,4 KB. Gepackt wurde mit WinRAR.
Beim SuperTeam Keybinder handelt es sich um Binäre Daten, falls das eine Rolle spielt.
Von daher kann dies heir wohl nicht mehr stimmen:

PackMemory() hat geschrieben:Hinweis: Der Kompressions-Algorithmus ist etwas langsam, ergibt aber sehr gute Resultate (besser als das .ZIP Format).

Um sicherzugehen habe ich 5 Sounddateien, davon 1 MIDI-Datei mit einer gesamtgröße von 150 KB mit PB komprimiert. Und mit WinRAR; wie immer, beides auf stärkster Komprimierung ausgerichtet.
150 KB => PB: 71,0 KB, RAR: 59,4 KB

Dasselbe Spielchen mit 12 kleinen PNG Grafiken, wobei zu sagen ist, dass PNG-Bilder schon von haus aus (verlustfrei) komprimiert werden.
Vorher: 40,0 KB; PB: 14,0 KB, RAR: 13,9 KB

Es steht also 3:0 für RAR (und ZIP) gegen PureBasic/JCalG1.

Ich schätze die unglaublich schnelle Dekompression, sodass man zur Laufzeit problemlos Bilder und Sounds entpacken und abspielen kann, ohne, dass man etwas von der Dekompression mitbekommt:

UnpackMemory() hat geschrieben:Hinweis: Das Dekomprimieren ist sehr sehr schnell, anders als das Komprimieren.

Gibt es noch irgendwo einen versteckten Schalter, wo 'Turbo' draufsteht, den man bei JCalG1 noch umlegen könnte?

Oder muss ich, wenn ich die totale Komprimierung will, auf andere Algorythmen umsteigen? Sollte nun etwas an der PB'ischen Komprimierung getan werden, wäre könnte dies ja noch vor dem PR von PB 4.00 geschehen, das träfe sich ja dann gut.
Das PB sogar von ZIP geschlagen wird, finde ich schon fast demütigend...

Eure Meinung(en) bitte:

Du setzt hier RAR mit ZIP gleich.
Das kann man nicht machen, da beide Algorithmen sich voneinandern unterscheiden. RAR benutzt Solid Mode/Solid Archiving Technique, ZIP benutzt Deflate.

Außerdem hast du nicht das Kompressionsverhältnis bei größeren Dateien untersucht. Die wenigsten komprimieren so kleine Dateien, wie du es machst. Meiner Meinung nach eignet sich eine Komprimierung ab so ~10 MB und mehr.
Man müsste also mal testen, wie schnell/langsam/effektiv die Algorithmen bei so großen Dateien sind.

Ich setze nicht ZIp mit RAR gleich, ich vergleiche lediglich PB—ZIP—RAR. Man kann wählen, ob man bei RAR die solide Archivierung aktivieren will, das habe ich bei obigen Tests nicht getan.

Ich habe gerade eine größere Datei getestet, eine 1280x1024x24 große BMP Datei, Größe: 5,00 MB

Die RAR gepackte Datei passt mit 1,37 MB noch auf eine Diskette (1,38 MB), PB gepackte Datei mit 1,46 MB schon nicht mehr.

ich finde den unterschied vernachlässigbar klein.
probier mal größere pakete zu erstellen, so zwischen 5 und 50 mb, vieleicht führt das ja zu anderen ergebnissen.

auch ist da die frage ob sich JCalG1 dafür schneller dekompremieren läßt.

ein besser oder schlechter ist keine so einfache frage, denn da spielen möglicherweise eine menge faktoren eine rolle.

Ich habe jetzt einmal eine 23,6 Mb große Hilfedatei des Formats HLP (*nicht* chm) mit RAR (nicht solid) und mit jcalg1 (PB) komprimiert.

3 Mal dürft ihr raten, wer gewonnen hat: RAR natürlich.

23,6 MB => PB: 5,46 MB, RAR: 4,41 MB.

Das heißt, das wir hier bereits die 1 Megabyte-Differenz-Grenze überschreiten...

Dann frag mal den Eugen Rosthal (Autor von RAR), wie hoch die
Lizenzgebühren für kommerziele Nutzung in einer Programmiersprache sind.

Wenn Du das dann in ein paar Jahren zusammengespart hast, kannst es an
Fred überweisen und der wird dies sicher implementieren

Fred hat wohl Zip und evtl. auch 7z auf seiner ToDo liste, aber das kann
dauern

7z ist ganz gut... besser als zip und rar <_<... zumindest in der Komrpistärke

Ich fand es zumindest immer ärgerlich das JCalG1 verwendet wird.

Da man mit Zip Dateien International keine Probleme hat.
Bei PB-JCalG1 muss ich immer den entpacker mitliefern, damit ich sicher bin das der Empfänger auch entpacken kann.

Zip ist zwar nicht das beste, aber Zip for President !

Wer Zip entwickeln will, hier ein anfang von mit:
http://www.purebasic.fr/english/viewtop ... 342#135342

Ich wollte auch schon mal in eins meiner Programme eine Möglichkeit zum Komprimieren von daten einbauen, anfangs hab ich´s mit den PB Befehlen versucht, das Ergebniss: Die Dateien waren auf höchstem Kompressionslevel ungefähr so groß wie die selben dateien bei mittlerer ZIP Kompression, aber die Dauer! Ich hab zum testen mal meine eigenen Dateien komprimiert, mit den PureZip Befehlen/WinZip hat es villeicht 1 Minute gedauert, bei JCalG1 hab ich´s nach einer Weile abgebrochen, weil mir zu lange gedauert hat und mich mit den 250kb mehr in der EXE (durch PureZip) abgefunden hatte. Das die dekomprimierung so rasend schnell sein soll konnte ich auch irgendwie nicht feststellen...

jCalG1:
für eigene Zwecke am besten geeignet, da das Packen ja nicht beim
User erfolgt, sondern lediglich das Entpacken. Die eigene Exe wird
auch nicht unnötig groß.

BreifLZ: Dieselbe Funktionalität wie jCalG1, aber schneller, die
Packrate ist etwas geringen. Lib für PB4 ready

ZIP: Umsetzung nach PB wäre lediglich Mithilfe von ZLib in
erträglichem Aufwand möglich.
Die Verwendung in kommerziellen Projekten ist kein Problem, aber
wenn nur die Funktionalität dort zur Verfügung gestellt wird, ist
dies erst zu Prüfen. (Diese Probleme entfallen bei kostenlosen
Userlibs, die nicht zum Lieferumfang von PureBasic gehören)
Für PB4 nur durch Import der statischen Lib, oder durch Nutzung
der zlib1.dll (Empfohlen von ZLib, da mit statischer Libs Probleme
auftreten können) zu verwenden.

Wenn Gnozal seine UserLib noch für PB4 kompilieren kann, ist doch
alles in Ordnung.

Wenn die Zip oder noch besser 7z Funktionalität in PB mal einfließt
ist es ein schönes Feature, aber ich sehe keinen Grund da zu
drängeln, da man sich ja bisher gut behelfen kann!