Ist die PB Komprimierung noch akzeptabel?

Für allgemeine Fragen zur Programmierung mit PureBasic.

JCalG1 - Deine Meinung?

Sollte verbessert werden
9
35%
Ist schon gut so / Keine Änderung nötig
10
38%
Es sollte ein anderer Algorytmus eingebaut werden
5
19%
Sollte völlig neu gelöst werden, z. B. gleich mit PW-Schutz, solide Archive, etc.
2
8%
 
Insgesamt abgegebene Stimmen: 26

Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Ist die PB Komprimierung noch akzeptabel?

Beitrag von AND51 »

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:
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
Benutzeravatar
Laurin
Beiträge: 1639
Registriert: 23.09.2004 18:04
Wohnort: /dev/eth0

Beitrag von Laurin »

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.
Now these points of data make a beautiful line.
And we're out of beta. We're releasing on time.
Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Beitrag von AND51 »

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.
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
Benutzeravatar
Zaphod
Beiträge: 2875
Registriert: 29.08.2004 00:40

Beitrag von Zaphod »

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.
Benutzeravatar
AND51
Beiträge: 5220
Registriert: 01.10.2005 13:15

Beitrag von AND51 »

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...
PB 4.30

Code: Alles auswählen

Macro Happy
 ;-)
EndMacro

Happy End
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag von ts-soft »

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 :mrgreen:

Fred hat wohl Zip und evtl. auch 7z auf seiner ToDo liste, aber das kann
dauern :mrgreen:
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Benutzeravatar
MVXA
Beiträge: 3823
Registriert: 11.09.2004 00:45
Wohnort: Bremen, Deutschland
Kontaktdaten:

Beitrag von MVXA »

7z ist ganz gut... besser als zip und rar <_<... zumindest in der Komrpistärke
Bild
Benutzeravatar
PAMKKKKK
Beiträge: 321
Registriert: 21.04.2005 22:08
Wohnort: Braunschweig
Kontaktdaten:

Beitrag von PAMKKKKK »

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

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 :allright: for President !

Wer Zip entwickeln will, hier ein anfang von mit:
http://www.purebasic.fr/english/viewtop ... 342#135342
Wir Schreiben ein PureBasic Buch.
Auch du kannst mitmachen!
http://www.purearea.net/pb/english/pure ... :Main_Page
Benutzeravatar
benpicco
Beiträge: 391
Registriert: 01.10.2004 15:32
Wohnort: im Code
Kontaktdaten:

Beitrag von benpicco »

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...
Johann Wolfgang von Geothe hat geschrieben:Wie dieses oder jenes Wort geschrieben wird, darauf kommt es doch eigentlich nicht an, sondern darauf, daß die Leser verstehen, was man damit sagen wollte.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Beitrag von ts-soft »

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!
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Antworten