ZLib Speed much slower than ZLibEx

[user69]

Hallo Gemeinde,

mir ist gerade aufgefallen, das die ZLib die mit Delphi kommt extrem langsamer ist, als die ZLibEx. Bei meinen Test der Faktor 4-5. (bei D10 Sydney und auch bei Berlin). Somit muss ich wohl auf die ZLibEx zurück gehen.

Hat das auch schon wer beobachtet oder ne idee woran es liegen kann?
Kann es evtl. sein, dass es daran liegt dass ich aus dem komprimieren nicht nen ganzen Block lese, sondern Datensatz per Datensatz (also ganz viele kleine stücke) und die ZLibEx besser cached?

[himitsu]

Erstmal kommt es drauf an wie du das benutzt.
mit Streams, DynArrays oder auf einem statischen Buffer, also ob die Funktionen direkt oder mit noch was dazwischen ... teilweise sind die Funktionen schon bissl "ungünstig" aufgebaut.

Ansonsten kann Embarcadero nicht direkt etwas für das Tempo.
Hier wird ein vorkompilierter Fremdcode benutzt, von dem ich jetzt aber nicht direkt sagen kann auswelcher Quelle das kommt und in welcher Version (vermutlich aber nicht sehr aktuell)

OK, vor 2 Jahren wurde das mal wieder aktualisiert.
Zlib 1.2.11 am 2018-07-05, wobei das zumindestens der aktuelle Code ist, welcher auch schonwieder 3 Jahre alt ist (2017 laut Wiki),
was aber nichts drüber aussagt wie das kompiliert wurde.

[user69]

Also ich verwende Stream.

Zusätzlich habe ich noch etwas probiert - leider ohne finalen Erfolg
- Die obj Files der ZLib zwischen Delphi ZLib und ZLib Ex unterscheiden sich in der Größe (ca. 50%) und sind nicht kompatibel (Die Version ist bei beiden 1.2.11)
- die 1.2.11 ZLib ist genauso schnell, wie die 1.2.8
- Eine angepasste ZLib für 1.2.11 ist hier zu finden: https://github.com/ValtsS/Delphi-ZlibEx (leider nur OBJ files für 32 bit)

Kann mir jemand die OBJ files für 64 bit erstellen (die zur ZLib 1.2.11 passen)? Da ich nur Delphi habe kann ich auf BCC32/64 nicht zugreifen.
Oder eine Link posten?

Da ich nicht recht rausfinde, warum die Delphi Version so langsam ist muss ich da eher aufgeben und einfach die ZLibEx nutzen.

Vielen Dank.

[user69]

Ich will das Thema noch mal mit nem Demo mit StopWatch (siehe attached) aufwärmen ... (bitte erst einmal Write nutzen vor nem Read)

Ich schreibe/lese ne Menge kleine Daten - hier mal als ein 160 MB File.
Dabei zeigt sich dass die ZLib gegen ZLibEx beim schrieben 2 mal so langsam ist. Beim Lesen sogar 10 mal so langsam.

Die Version bei ZLib ist neuer und ZLibEx wird auch wohl nicht mehr gewartet. Deshalb wollt ich ja umsteigen.
Aber bei dem Speed geht das nicht.

Kann das an dem Cache von ZLibEx liegen oder sind die Delphi zlib obj Files schlecht erstellt.

[KodeZwerg]

Auch schon benchmarks vs zip durchgeführt?

[himitsu]

Die ZIP-Klasse im Delphi benutzt auch nur die ZLib-Unit.

Man kann auch die DLL von 7-Zip verwenden, wo auch ein ZIP / ZLib oder ZLibEx drin ist.
Aber k.A. wie schnell/aktuell deren Implementierung ist. (könnte man in den Sourcen nachsehn, wenn man Langeweile hat)

[user69]

ZIP hab ich nicht weiter getestet - ich nutz die gzip Komprimierung on the fly während dem Speichern und Laden.
Eine DLL kommt leider für meinen Einsatz nicht in Frage.

Ich vermute auch das in 64bit folgende ZLibEx.pas Zeile Probleme macht:

Move(Pointer(Integer(param^.InBuffer) + param^.InPosition)^, buffer, result); //in ZBufferRead

Müsste das nicht eher zu NativeInt geändert werden um 64 bit kompatibel zu sein?

Move(Pointer(NativeInt(param^.InBuffer) + param^.InPosition)^, buffer, result);

[himitsu]

Ja.

Oder weglassen?
-> Direkt nach Pointer casten.
Ups, bei den Klammern verrutscht.

Wenn Pointer-Arithmetik aktiv ist (könnte aber jemand so unnett sein und es deaktivieren), dann kann man z.B. auch PByte für solche Casts benutzen.


Es müsste auch eine .O .OBJ geben, bzw. die sollte man sich aus den Quellcodes kompilieren können,
welche sich dann wie ZLib/RegEx/JPeg/... ins Delphi einkompilieren liese. (wenn jemand so schlau ist und die passende ImportUnit dafür schreiben kann)

[user69]

>Direkt nach Pointer casten
Wie würde das gehen (wegen der Addition)? Beispiel?

[himitsu]

War ein Denk-/Guckfehler.
Hatte es grade oben im Post nochmal berichtig.

Ja, würde gehen, aber nur mit einem Typen, der hierfür 1 Byte groß sind.
z.B. PByte


Würde das Offset z.B. 4 sein, also p+x*4, dann wäre auch ein 4 Byte-Typ OK und dann das *4 weglassen, weil es implizit über den Typ vom Compiler rein kommt.