PureCrunch - Eine simple Fast-Compression-UserLib für PB

Anwendungen, Tools, Userlibs und anderes nützliches.
Benutzeravatar
al90
Beiträge: 1103
Registriert: 06.01.2005 23:15
Kontaktdaten:

Beitrag von al90 »

Rings hat geschrieben: Ja klar, mach deinen Buffer Größer, es gibt keinen Sinn (IMHO) nur 6kb pakete zu packen, wenn dann hab ich immer 100kb aufwärts zupacken.
Also ich denke ob 6KB oder 100KB spielt ja im grunde auch keine rolle.
Es wird ja definitiv immer die ganze datei gepackt. Kann also bis 2GB gehen.
Wie der code am ende aussieht, wird dem Endanwender dann eh egal sein.
Noch nie ein Problem damit. Benutzt du BriefLZ aus der PBOSL ?
evtl. den Callback auf Nullsetzen
Ja die von PBOSL. Den CallBack habe ich bereits auf null gesetzt. (siehe mein beispielcode oben)
Gibts im letzen Parameter zurück,siehe mein Beispiel
Ah so geht das. Ok werde ich mir dann später nochmal ansehen.
Wenn du das mit dem Buffer geändert hast werd ich nochmals testen.
Mit dieser Buffer-Beschränkung iss so net so richtig zu gebrauchen
Naja wie gesagt, Eine datei wird eh Häppchenweise gepackt. Ist ja dann
im grunde egal welche buffersize man als programmierer nimmt. Der End-
anwender sieht eh nur das fertige produkt. Aber lassen wir das jetzt.
Wenn dir das so nicht gefällt, dann respektiere ich das natürlich. :wink:
Wenn man Sachen zeitunkritisch packen kann wird jcalg oder
ZIP meist die beste wahl sein.
Klar, meistens schon. Aber wie ich ja schon sagte ist PureCrunch in vielen tests
sogar bis zu 30% schneller gewesen als zip. Getestet habe ich es mit FB,
wobei ich nur die syntax ausgetauscht hatte. Ich denke für zeitkritische sachen ist
PureCrunch also eine gute alternative. :wink:
pbnewby
Beiträge: 34
Registriert: 21.01.2008 16:10

Beitrag von pbnewby »

Ist ja dann
im grunde egal welche buffersize man als programmierer nimmt.
Stimmt aber nicht ganz. Je grösser der Puffer, je besser die Chance für den Kompressions-Algorithmus besser zu Packen. Warum sonst bieten einige Packer (7z, ACE, RAR usw) Buffergrössen bis zu 4MB oder sogar sogar über 1GB (!) an?
-=[ PBNewBy ]=-
Benutzeravatar
al90
Beiträge: 1103
Registriert: 06.01.2005 23:15
Kontaktdaten:

Beitrag von al90 »

Neue version verfügbar
v1.1

Geändert: Die Funktion PC_GetPureCrunchVersion() wurde entfernt.
Stattdessen kann nun die konstante #PC_Version$ verwendet werden.

Hinzugefügt: PC_CrunchLargeMemory() & PC_DeCrunchLargeMemory()
Diese sind nun nicht mehr auf 65535 Bytes beschränkt und bieten außerdem eine möglichkeit CallBacks zu benutzen.

Hinzugefügt: PC_GetDeCrunchedSize() zum ermitteln der original (ungepackten) länge eines gecrunchten speicherbereichs.

Hinzugefügt: #PC_ProcessFail & #PC_ProcessBreak zum abfragen und abbrechen von prozessen.
Das update kann über den LibraryUpdater oder meiner Seite geladen werden.
Benutzeravatar
Thorium
Beiträge: 1722
Registriert: 12.06.2005 11:15
Wohnort: Germany
Kontaktdaten:

Beitrag von Thorium »

Das ist sehr interessant.
Schnelle Packer/Unpacker kann ich immer gut gebrauchen.

Was ich am besten gebrauchen könnte, währe ein Packer, der mir kleine Speicherbereiche sehr schnell packt und entpackt. Dabei kann die Kompressionsrate ruhig schlechter sein als zip etc. Hauptsache das Teil ist schnell wie der Wind. ^^

Also bräuchte nen Algorythmus der gut mit 50kb bis 1MB Datengröße zurechtkommt.

Ist deiner dafür geeignet?

Edit:
Ah, nochwas.
Bei meinen Datenblöcken macht Runlength-Encoding keinen Sinn, ist sehr selten das da mal mehrere gleiche Bytes aufeinanderfolgen. Also am besten würde was funktionieren, was irgendwie gleiche Muster zusammenfast oder so. Kenne mich net so gut aus mit Kompressionsverfahren.
Zu mir kommen behinderte Delphine um mit mir zu schwimmen.

Wir fordern mehr Aufmerksamkeit für umfallende Reissäcke! Bild
Benutzeravatar
al90
Beiträge: 1103
Registriert: 06.01.2005 23:15
Kontaktdaten:

Beitrag von al90 »

Thorium hat geschrieben: Also bräuchte nen Algorythmus der gut mit 50kb bis 1MB Datengröße zurechtkommt.

Ist deiner dafür geeignet?
Ja. Wenn du also z.b. 50kb grössen packen möchtest, würde ich die PC_CrunchMemory() funktion empfehlen.
Diese erlaubt es Speicherbereiche bis zu 65535 bytes zu komprimieren.
Ansonsten kann die neue funktion PC_CrunchLargeMemory() benutzt werden.
Dabei liegt das limit beim maximalen verfügbaren speicher. (Also max. 2GB)
Edit:
Ah, nochwas.
Bei meinen Datenblöcken macht Runlength-Encoding keinen Sinn, ist sehr selten das da mal mehrere gleiche Bytes aufeinanderfolgen. Also am besten würde was funktionieren, was irgendwie gleiche Muster zusammenfast oder so. Kenne mich net so gut aus mit Kompressionsverfahren.
Keine sorge, PureCrunch ist kein simpler RLE-Algo abklatsch. :wink:
Die gleichheiten von Bytefolgen können auch verstreut im memory liegen.
Benutzeravatar
al90
Beiträge: 1103
Registriert: 06.01.2005 23:15
Kontaktdaten:

Beitrag von al90 »

Neue version 1.1a verfügbar.

Viel neues gibts zwar nicht, aber dafür läuft es jetzt auch mit PB4.30. (NeuCompilierung)

Ausserdem habe ich nun auch ein Deutsches CHM-File beigelegt. :wink:
Antworten