[Linux] Welches Programm zippt mit Zstd?

[Alexander2]

Das finde ich interessanter (Firefox Cache Ordner)

 #  --- Standardwerte ---
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | zstd - -o zstd-standard.tar.zstd                                                                                                            1 ↵
/*stdin*\            : 64.19%   (   437 MiB =>    281 MiB, zstd-standard.tar.zstd)
tar cf - firefox                      0,00s user 0,09s system 59%  cpu 0,165 total
zstd - -o zstd-standard.tar.zstd      0,63s user 0,14s system 407% cpu 0,189 total
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | lz4 - lz4-standard.tar.lz4        
Compressed 458219520 bytes into 340872325 bytes ==> 74.39%                    
tar cf - firefox                      0,01s user 0,08s system 28%  cpu 0,287 total
lz4 - lz4-standard.tar.lz4          0,40s user 0,14s system 187% cpu 0,288 total



#  --- Definierte Level ---
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | lz4 -1 - lz4-1.tar.lz4
Compressed 458219520 bytes into 340872325 bytes ==> 74.39%                    
tar cf - firefox                  0,01s user 0,07s system 29%  cpu 0,281 total
lz4 -1 - lz4-1.tar.lz4          0,39s user 0,16s system 192% cpu 0,282 total

╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | lz4 -4 - lz4-4.tar.lz4
Compressed 458219520 bytes into 322070512 bytes ==> 70.29%                    
tar cf - firefox                  0,01s user 0,08s system 28%   cpu 0,321 total
lz4 -4 - lz4-4.tar.lz4          5,57s user 0,20s system 1521% cpu 0,380 total

╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | zstd -1 - -o zstd-1.tar.zstd
/*stdin*\            : 66.56%   (   437 MiB =>    291 MiB, zstd-1.tar.zstd)  
tar cf - firefox                  0,01s user 0,07s system 60%  cpu 0,127 total
zstd -1 - -o zstd-1.tar.zstd      0,38s user 0,11s system 383% cpu 0,129 total

╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | zstd -4 - -o zstd-4.tar.zstd
/*stdin*\            : 64.02%   (   437 MiB =>    280 MiB, zstd-4.tar.zstd)  
tar cf - firefox                  0,00s user 0,08s system 47%  cpu 0,180 total
zstd -4 - -o zstd-4.tar.zstd      0,72s user 0,10s system 396% cpu 0,206 total



#  --- rest ---
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla 
╰─$ time tar cf - firefox | lz4 -7 - lz4-7.tar.lz4         
Compressed 458219520 bytes into 321003672 bytes ==> 70.05%                    
tar cf - firefox  0,01s user 0,08s system 26% cpu 0,340 total
lz4 -7 - lz4-7.tar.lz4  6,70s user 0,18s system 1669% cpu 0,412 total
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ time tar cf - firefox | lz4 -9 - lz4-9.tar.lz4
Compressed 458219520 bytes into 320805574 bytes ==> 70.01%                    
tar cf - firefox  0,01s user 0,09s system 27% cpu 0,345 total
lz4 -9 - lz4-9.tar.lz4  8,29s user 0,18s system 1819% cpu 0,465 total
╭─alexander@alexander-x370professionalgaming ~/.cache/mozilla
╰─$ ls -lha                                      
insgesamt 2,4G
drwx------ 1 alexander alexander  262 13. Feb 00:48 .
drwxr-xr-x 1 alexander alexander 6,1K 12. Feb 22:55 ..
drwx------ 1 alexander alexander  136 29. Nov 2024  firefox
-rw-r--r-- 1 alexander alexander 326M 13. Feb 00:25 lz4-1.tar.lz4
-rw-r--r-- 1 alexander alexander 308M 13. Feb 00:28 lz4-4.tar.lz4
-rw-r--r-- 1 alexander alexander 307M 13. Feb 00:48 lz4-7.tar.lz4
-rw-r--r-- 1 alexander alexander 306M 13. Feb 00:48 lz4-9.tar.lz4
-rw-r--r-- 1 alexander alexander 326M 13. Feb 00:34 lz4-standard.tar.lz4
-rw-r--r-- 1 alexander alexander 291M 13. Feb 00:32 zstd-1.tar.zstd
-rw-r--r-- 1 alexander alexander 280M 13. Feb 00:32 zstd-4.tar.zstd
-rw-r--r-- 1 alexander alexander 281M 13. Feb 00:34 zstd-standard.tar.zstd

Kommt aber zugegebenermaßen zu keinem anderem Ergebnis, zstd ist auch sauschnell. Komprimiert dabei besser.
Dabei ist dann beim Dekomprimieren hinterher bei um die halbe Geschwindigkeit zu erwarten insofern der Datenträger mitkäme, was heute garnicht mehr so umgewöhnlich ist auf beide betrachtet.

Ich werd mein Borg archiv aber auch lz4 lassen :-)
und sonst wohl auch dabei bleiben, es sei denn ich bräuchte die beste komprimierung.

Ergänzung (13. Februar 2026)

Versteht denn Windows das Format dann noch von den Zip Dateien mit dem zstd ? das wäre ja was mich daran noch interesseirt, ist das vielleicht für die @Krik komplett unwichtig?

 

[Krik]

@Alexander2
Windows-Unterstützung ist für mich gar nicht wichtig. Ich habe eben noch überlegt, ob ich vielleicht noch mit dem Handy darauf zugreife, aber das mache ich auch nicht. 🤔
.tar.zstd würde mir daher wahrscheinlich ausreichen.

Solche Tests wie eure habe ich aber nicht gemacht. Es war aber interessant zu lesen, wie sich das bei euch verhält. 🥸👍

 

[foofoobar]

Das finde ich interessanter (Firefox Cache Ordner)

Alles was bereits komprimiert ist (*.mp[43] *.jpg *.gz) wird beim erneuten komprimieren nicht signifikant kleiner.

Und verschlüsselte Daten werden beim komprimieren auch nicht nicht signifikant kleiner:

$ dd if=/dev/zero bs=1024k count=1024 2>/dev/null | openssl enc -aes-256-cbc -nosalt -pbkdf2 -pass pass:wurst | wc -c
1073741840
$ dd if=/dev/zero bs=1024k count=1024 2>/dev/null | openssl enc -aes-256-cbc -nosalt -pbkdf2 -pass pass:wurst | zstd | wc -c
1073766429
$

 

[Pummeluff]

Windows-Unterstützung ist für mich gar nicht wichtig. Ich habe eben noch überlegt, ob ich vielleicht noch mit dem Handy darauf zugreife, aber das mache ich auch nicht. 🤔
.tar.zstd würde mir daher wahrscheinlich ausreichen.

Bis zu Deinem Beitrag wusste ich nicht mal, dass Zip was anderes als zip kann. Aus Gewohnheit der letzten 20 Jahre verwende ich bis auf zip, 7z und rar nur tar. tar mit gzip, bz2, xz und auch zstandard. Mir fällt auch kein Grund ein, warum man da zip verwenden sollte. tar ist die Standard-Lösung unter unixoiden Betriebssystemen.

 

[foofoobar]

Mir fällt auch kein Grund ein, warum man da zip verwenden sollte. tar ist die Standard-Lösung unter unixoiden Betriebssystemen.

Und bei tar kann man ganz schmerzfrei den Kompressor wechseln, auch nachträglich ohne das eigentliche archiv anzufassen.

Unix Philosophie halt: Do only one thing, but do it right!

 

[Krik]

Ich habe meinen eigenen Test zur Geschwindigkeit der Zstd-Level gemacht.

#!/usr/bin/env bash

tar -cf firefox-profile.tar firefox-profile

for i in {1..22}; do
    echo "Testing Zstd level ${i}"
    time zstd --ultra -"${i}" firefox-profile.tar -o "zstd-${i}.tar.zstd"
done

echo "Completed"

Die .tar-Datei enthält 3.841 Dateien in 1.045 Verzeichnissen und ist 2.272.854.427 Bytes groß (= 2,1 GB).

Spoiler: Tabelle

Kompressionsgeschwindigkeit ist ein doofes Wort, aber ich habe nichts besseres gefunden. Es errechnet sich aus Kompressionsvorteil/Zeit in Minuten. Es soll anschaulicher machen, wie viel Kompressionsleistung pro Zeiteinheit erreicht wurde.

Spoiler: Graph Kompressionsfaktor

So viel verbessert sich der Kompressionsfaktor eigentlich gar nicht je Zstd-Level.

Spoiler: Graph Kompressionsgeschwindigkeit

• Also wenn ich mir das so anschaue, ist Level 12 für mich noch vertretbar, aber alles danach zu langsam für zu wenig wenig Gewinn beim Kompressionsfaktor.
• Level 1 bis 12 scheinen bei der Kompressionsgeschwindigkeit ungefähr auf einer Linie zu legen. Ausnahmen sind hier Level 7-9, wo wahrscheinlich andere Faktoren wie I/O-Durchsatz, Cache-Größe, etc. eine günstige Konstellation bilden.
• Ab Level 13 sieht man, dass der Algorithmus durch verschiedene Limits ausgebremst wird.

 

[Donnerkind]

In deinem Beispiel scheinen die Dateien nur schlecht komprimibel zu sein.

Ich hab auch schon ein paar Mal solche Benchmarks gemacht, um für mich zu entscheiden, wie ich z.B. automatisch generierte Dateilisten (also Textdateien von mehreren Megabyte Größe) komprimiere; zstd oder xz. Wenn es um die kleinste Dateigröße geht (z.B. fürs Archivieren auf dem NAS), nehme ich tatsächlich 7z, weil es nochmal besser ist als tar + xz oder zstd. Die Standardstärke bei zstd ist ja 6. Aber wie man bei deinem Test sieht, ist für alltägliche Nutzung spätestens 12 der Grenzwert, nach dem der Aufwand unproportional steigt für ein paar kB weniger Größe.

ich mags schnell, ist aber sowas von schnell

Je nach Anwendungsfall ist Schnelligkeit sicher schön. Aber selten packt man etwas, um es dann sofort wieder zu entpacken, sondern um den Speicherplatzbedarf oder das Übertragungsvolumen im Netzwerk zu verringern. Gerade bei ersterem wäre mir die Platzeffizienz wichtiger, als nicht ein paar Sekunden auf eine bessere Komprimierung zu warten.

Fernab unserer Diskussion ist es aber auf jeden Fall beachtlich, wie viel besser diese modernen Algorithmen gegenüber den Klassikern sind. Gzip und bzip komprimieren weit weniger gut trotz vielfach höheren Aufwands und xz braucht einfach nur eeeeewig.

Ergänzung (13. Februar 2026)

In deinem Beispiel scheinen die Dateien nur schlecht komprimibel zu sein.

Ich hab mal eine von meinen großen Textdateien mit zstd komprimiert. Die Datei enthält die Ausgabe von tree mitsamt Details für den gesamten Speicherpool auf meinem NAS, enthält 175000 Zeilen und ist entpackt 25 MB groß. Ausgeführt auf einem Surface Go 3 mit einem Core i3-10100Y.

q   Kompr.  Größe     Zeit
-----------------------------
01  14.78%  3.56 MiB  0,087 s
02  14.49%  3.49 MiB  0,083 s
03  14.36%  3.46 MiB  0,118 s
04  14.32%  3.45 MiB  0,172 s
05  13.71%  3.30 MiB  0,237 s
06  13.07%  3.15 MiB  0,296 s
07  12.99%  3.13 MiB  0,344 s
08  12.52%  3.02 MiB  0,422 s
09  12.45%  3.00 MiB  0,456 s
10  12.38%  2.98 MiB  0,594 s
11  12.35%  2.97 MiB  0,808 s
12  12.34%  2.97 MiB  0,830 s
13  12.31%  2.97 MiB  1,900 s
14  12.27%  2.95 MiB  2,258 s
15  12.20%  2.94 MiB  3,110 s
16  11.94%  2.88 MiB  5,068 s
17  11.37%  2.74 MiB  6,905 s
18  11.26%  2.71 MiB  8,896 s

gz          3.48 MiB  0,464 s
bz2         2.71 MiB  2,462 s
xz          2.43 MiB  9,116 s
7z          2.50 MiB  6,761 s

Die Ergebnisse liegen auch relativ dicht beieinander, von 14,8 bis 11,3 %. Also eine Verbesserung von etwa einem Drittel, bei Verhunderfachung des Rechenaufwands. Auch hier ist eine Zeitverdoppelung zwischen den Stufen 12 und 13 zu sehen – ohne siginifikante Verbesserung. Da wird wohl irgendein Parameter verändert, die vielleicht nur bei bestimmten Daten wirklich etwas bringt.

 

[Alexander2]

Für meine Fälle ist es meist kurzfristige archivierung, tar würde schon reichen, aber da die komprimierung einiger codecs so fix ist, warum nicht.
Und der andere Standardfall ist Borg Backup per Vorta GUI

Da ist deduplication die ultimative Datenersparnis und das was noch gut zu komprimieren geht soll dann auch fix gehen. die Sicherung wir Jeden Tag vom Home Verzeichnis gemacht. Schnell ist key.

Das meiste das ich mal verschicke ist nen Video, nen kurzes, oder Bilder .. da ist sowieso nichts mitm zip codec zu holen.
Edit:

Für nen Eindruck:

Beim Start mit eine der größten Sicherungen war dann 59gb glaube etwa jedenfalls bei 9 Minuten rum. und dann ist das System frei von der Last, kein ewiges rumgerödel. Sicherung auf eine 8TB herkömmliche HDD jedoch ein SMR Modell, wer das kennt .. groß und gut für Sicherungen geeignet. Ist auch noch was anderes Drauf, und hat grad nen Füllstand bei 67%

 

[Donnerkind]

Ich nutze bei Borg auch zstd -6 – damit sichere ich alles vom Betriebssystem über home bis zu meiner Musiksammlung und ein paar Videoverzeichnissen. Allerdings nicht so oft, einmal pro Woche bis einmal pro Monat.

 

[Alexander2]

Man kann dann ja auch irgendwann mal ausdünnen

Hatte damals auch nach dem umbau vom 3900x zum 5800er das neue archiv angefangen. Habs aber beim umbau Board + 9950X3d so beibehalten.

 

[Donnerkind]

Ich nutze bei Borg auch zstd -6 – damit sichere ich alles vom Betriebssystem über home bis zu meiner Musiksammlung und ein paar Videoverzeichnissen.

Nachtrag: auf meinem Raspi 3B und meiner Datenpartition (mit den vielen Mediendateien) wird tatsächlich lz4 statt zstd genutzt. Keine Ahnung mehr warum. Vielleicht hab ich auf mehr Effizienz gehofft, weil ich compression=auto,lz4 nutze und bei auto die Daten testweise mit lz4 komprimiert werden, sodass diese Daten vielleicht gleich verwendet werden.

 

[Piktogramm]

Ich verstehe die beiden MB/s Werte hintereinander pro Zeile nicht ganz, ein bischen Erklärung dazu wäre Hilfreich zum Verständnis, auch wenn ich sehe, das bei lz4 die deutlich größeren Werte auftauchen.

Für die aller meisten Terminaltools gibt es Manpages, da ist im Normalfall alles dokumentiert. Gewöhn dir bitte an die entsprechenden Manpages selbstständig zu lesen, wenn dir Funktion/Ausgabe nicht einleuchtet. Das tippen von man foobar samt Lesen des Ganzen geht meist auch viel schneller als das Schreiben einer Frage und das Warten auf eine Antwort..
Analog gilt das Selbe für eigenständige Recherche im Duden, Wikipedia, Normen, ..

es ist zumindest näher an der üblich genutzten DAten dran als ein Datum also Text, mit nur ca 10 byte oder so das komprimiert werden soll.

Und du weißt das ganz genau was ich meine.

"üblich genutzte Daten" gibt es halt nicht. Meist ist damit "das was ich für richtig halte" gemeint, was aber von Person zu Person, zu Anwendungsfall zu Anwendungsfall extrem streuen kann. Daher definiert man für einen gescheiten Vergleich im Regelfall auch statische Testdatensätze.
Lorem Ipsum aus dem Zufallsgenerator ist für einen groben Vergleich ausreichend und kann als Platzhalter für Texte romanischer Sprachen gelten.

Wobei, bei mir steht lorem ipsum, das scheint anders zu sein.
Und hat nur einen Kern genutzt.

Wahrscheinlich andere Version der Programme.
Lies die Manpages, siehst du bei mir Optionen, die darauf deuten lassen, dass mehr als ein Kern zum Einsatz kam? Ich habe nur dazu geschrieben, dass Tests mit mehr Kernen wenig sinnvoll waren.

 

[Alexander2]

Wieviele Kerne bei dir zum Arbeiten kamen kann ich nicht sagen, ich habe das nur bei mir beobachtet, das zumindest der Taskmanager beid er Kurzen Arbeit nicht mehr erfassen konnte. der time Befehl ist da dann doch genauer das zu erfassen als nebenher in einen Taskmanager zu schauen.

Bei anderen Arbeitslasten waren es ja zum Teil auch mal um die 16 Kerne

 

[foofoobar]

echo "Completed"[/CODE]
Die .tar-Datei enthält 3.841 Dateien in 1.045 Verzeichnissen und ist 2.272.854.427 Bytes groß (= 2,1 GB).

Spoiler: Tabelle

Anhang anzeigen 1705752

Wahrscheinlich gibt es dort einfach wenig zu komprimieren weil ein großer Teil der Daten bereits komprimiert oder verschlüsselt ist.

Hier das mal auf der CMD-Line für source-code durchgenudelt.
Time2Size bzw. dessen Kehrwert ist ein Faktor für den zeitlichen Mehraufwand gegenüber dem erreichten kleinsten Kompressionsfaktor und dem Faktor um welche die Kompression besser ist.

$ before=$(cat x.tar | wc -c); for i in $(seq 1 9); do /bin/time -f "%e" -o /tmp/time lz4 -$i -c < x.tar | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      0.38116      0.26367      1.84000      1.00000      0.78566      3.79265      0.26367
           2      1.44561      0.38116      0.26367      1.78000      0.96739      0.81214      3.66897      0.27256
           3      1.44561      0.28346      0.19608      6.75000      3.66848      0.21416     18.70882      0.05345
           4      1.44561      0.27802      0.19232      8.25000      4.48370      0.17523     23.31382      0.04289
           5      1.44561      0.27493      0.19018     10.38000      5.64130      0.13927     29.66295      0.03371
           6      1.44561      0.27308      0.18891     13.01000      7.07065      0.11112     37.42935      0.02672
           7      1.44561      0.27213      0.18824     16.33000      8.87500      0.08852     47.14646      0.02121
           8      1.44561      0.27164      0.18791     20.22000     10.98913      0.07149     58.48200      0.01710
           9      1.44561      0.27127      0.18765     25.03000     13.60326      0.05776     72.49335      0.01379
$ before=$(cat x.tar | wc -c); for i in $(seq 1 9); do /bin/time -f "%e" -o /tmp/time gzip -$i -c < x.tar | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      0.29086      0.20121      7.58000      1.00000      0.19071      4.97004      0.20121
           2      1.44561      0.27624      0.19109      7.96000      1.05013      0.18161      5.49560      0.18196
           3      1.44561      0.26566      0.18377      9.67000      1.27573      0.14949      6.94189      0.14405
           4      1.44561      0.24666      0.17063     10.09000      1.33113      0.14327      7.80137      0.12818
           5      1.44561      0.23502      0.16258     13.67000      1.80343      0.10575     11.09285      0.09015
           6      1.44561      0.22893      0.15836     21.16000      2.79156      0.06832     17.62738      0.05673
           7      1.44561      0.22682      0.15690     26.19000      3.45515      0.05520     22.02121      0.04541
           8      1.44561      0.22479      0.15550     38.22000      5.04222      0.03782     32.42645      0.03084
           9      1.44561      0.22460      0.15537     42.66000      5.62797      0.03389     36.22320      0.02761
$ before=$(cat x.tar | wc -c); for i in $(seq 1 19); do /bin/time -f "%e" -o /tmp/time zstd -$i -c < x.tar | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      0.23354      0.16155      2.00000      1.00000      0.72280      6.19003      0.16155
           2      1.44561      0.22170      0.15336      2.06000      1.03000      0.70175      6.71610      0.14890
           3      1.44561      0.20670      0.14299      2.46000      1.23000      0.58765      8.60220      0.11625
           4      1.44561      0.20590      0.14243      2.60000      1.30000      0.55600      9.12699      0.10957
           5      1.44561      0.18860      0.13047      5.71000      2.85500      0.25317     21.88324      0.04570
           6      1.44561      0.18026      0.12469      8.22000      4.11000      0.17586     32.96066      0.03034
           7      1.44561      0.17669      0.12223      9.19000      4.59500      0.15730     37.59433      0.02660
           8      1.44561      0.17396      0.12033     11.29000      5.64500      0.12804     46.91127      0.02132
           9      1.44561      0.16998      0.11759     11.44000      5.72000      0.12636     48.64510      0.02056
          10      1.44561      0.16766      0.11598     15.14000      7.57000      0.09548     65.27058      0.01532
          11      1.44561      0.16636      0.11508     20.00000     10.00000      0.07228     86.89703      0.01151
          12      1.44561      0.16625      0.11501     22.24000     11.12000      0.06500     96.69054      0.01034
          13      1.44561      0.16555      0.11452     42.89000     21.44500      0.03371    187.25541      0.00534
          14      1.44561      0.16384      0.11333     54.21000     27.10500      0.02667    239.16158      0.00418
          15      1.44561      0.16212      0.11215     72.55000     36.27500      0.01993    323.45994      0.00309
          16      1.44561      0.15486      0.10713    112.30000     56.15000      0.01287    524.14655      0.00191
          17      1.44561      0.14758      0.10209    141.42000     70.71000      0.01022    692.61496      0.00144
          18      1.44561      0.14597      0.10098    187.62000     93.81000      0.00770    929.01746      0.00108
          19      1.44561      0.14261      0.09865    316.47000    158.23500      0.00457   1603.97050      0.00062
$

 

[Krik]

@foofoobar
Mit dem Parameter --ultra kannst du bei zstd die Level 19 bis 22 freischalten. Keine Ahnung, ob er da bei dir noch eine nennenswerte Verbesserung des Komprimierungfaktors hervorbringen kann.

Und ja, das FF-Profil scheint im Wesentlichen aus einer DB zu bestehen. Die wird wohl schon irgendeine Form der Komprimierung verwenden.

 

[Piktogramm]

Die Standardstärke bei zstd ist ja 6. Aber wie man bei deinem Test sieht, ist für alltägliche Nutzung spätestens 12 der Grenzwert, nach dem der Aufwand unproportional steigt für ein paar kB weniger Größe.

Zstd wechselt mit den Kompressionsleveln auch extrem das Verhalten für die Suche.
https://facebook.github.io/zstd/doc/api_manual_latest.html#Chapter5

typedef enum { ZSTD_fast=1,
               ZSTD_dfast=2,
               ZSTD_greedy=3,
               ZSTD_lazy=4,
               ZSTD_lazy2=5,
               ZSTD_btlazy2=6,
               ZSTD_btopt=7,
               ZSTD_btultra=8,
               ZSTD_btultra2=9
               /* note : new strategies _might_ be added in the future.
                         Only the order (from fast to strong) is guaranteed */
} ZSTD_strategy;

Wobei die Strategien nicht 1zu1 auf die Kompressionslevel passen. Das Mapping gibt es dann hier: https://github.com/facebook/zstd/blob/dev/lib/compress/clevels.h
Erklärung zum Struct:

typedef struct {
    unsigned windowLog;       /**< largest match distance : larger == more compression, more memory needed during decompression */
    unsigned chainLog;        /**< fully searched segment : larger == more compression, slower, more memory (useless for fast) */
    unsigned hashLog;         /**< dispatch table : larger == faster, more memory */
    unsigned searchLog;       /**< nb of searches : larger == more compression, slower */
    unsigned minMatch;        /**< match length searched : larger == faster decompression, sometimes less compression */
    unsigned targetLength;    /**< acceptable match size for optimal parser (only) : larger == more compression, slower */
    ZSTD_strategy strategy;   /**< see ZSTD_strategy definition above */
} ZSTD_compressionParameters;

Gerade bei 12 zu 13 gibt es ein Wechsel von lazy2 zu btlazy2 . Was die Strategien algorithmisch machen suche ich nicht raus. Ich nerdsnipe mich gerade sowieso zu doll.

Ich hab mal eine von meinen großen Textdateien mit zstd komprimiert. Die Datei enthält die Ausgabe von tree mitsamt Details für den gesamten Speicherpool auf meinem NAS, enthält 175000 Zeilen und ist entpackt 25 MB groß. Ausgeführt auf einem Surface Go 3 mit einem Core i3-10100Y.
[...]
Die Ergebnisse liegen auch relativ dicht beieinander, von 14,8 bis 11,3 %. Also eine Verbesserung von etwa einem Drittel, bei Verhunderfachung des Rechenaufwands. Auch hier ist eine Zeitverdoppelung zwischen den Stufen 12 und 13 zu sehen – ohne siginifikante Verbesserung. Da wird wohl irgendein Parameter verändert, die vielleicht nur bei bestimmten Daten wirklich etwas bringt.

Die Suchfenster von Zstd sind schon bei geringeren Kompressionsleveln größer als deine paar MB. Den Vorteil größerer Suchfenster kann dein Test also schon nicht zeigen. Der Unterschied ist aber auch mit der 10fachen Datenmenge nicht gravierend.
Und großartig anders werden sich die meisten Datensätze nicht verhalten. Datenströme, die auf kleinem Maßstab zufällig wirken, aber dann in größeren Betrachtungsfenstern gut komprimierbare Muster zeigen und dabei realen Nutzwert[1] haben sind selten.

[1] Strukturiertes Rauschen lässt sich erzeugen, der Nutzwert davon ist oftmals halt nicht gegeben.

Wieviele Kerne bei dir zum Arbeiten kamen kann ich nicht sagen

Der Hinweis auf die Manpage war evtl, weil dort Argumente und Threading dokumentiert sind. Keine Ahnung, müsse mal einer lesen.

 

[Alexander2]

Das hab ich doch schon längst, ich habe außer nem gefällt mir nur nichts weiter davon erwähnt.

Und das geht ganz automatisch. (Standard ist auto)

 

[foofoobar]

Ich habe die Tests von oben noch mal über Rauschen der gleichen Größe laufen lassen:

$ before=$(cat Noise | wc -c); for i in $(seq 1 9); do /bin/time -f "%e" -o /tmp/time lz4 -$i -c < Noise | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      1.44561      1.00000      0.84000      1.00000      1.72096      1.00000      1.00000
           2      1.44561      1.44561      1.00000      0.81000      0.96429      1.78470      0.96428      1.03704
           3      1.44561      1.44561      1.00000     21.74000     25.88095      0.06650     25.88093      0.03864
           4      1.44561      1.44561      1.00000     22.19000     26.41667      0.06515     26.41664      0.03785
           5      1.44561      1.44561      1.00000     22.54000     26.83333      0.06414     26.83331      0.03727
           6      1.44561      1.44561      1.00000     22.19000     26.41667      0.06515     26.41664      0.03785
           7      1.44561      1.44561      1.00000     22.34000     26.59524      0.06471     26.59521      0.03760
           8      1.44561      1.44561      1.00000     22.14000     26.35714      0.06529     26.35712      0.03794
           9      1.44561      1.44561      1.00000     22.41000     26.67857      0.06451     26.67855      0.03748
$ before=$(cat Noise | wc -c); for i in $(seq 1 9); do /bin/time -f "%e" -o /tmp/time gzip -$i -c < Noise | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      1.44585      1.00017     21.48000      1.00000      0.06730      0.99983      1.00017
           2      1.44561      1.44585      1.00017     21.43000      0.99767      0.06746      0.99750      1.00250
           3      1.44561      1.44585      1.00017     21.29000      0.99115      0.06790      0.99099      1.00910
           4      1.44561      1.44584      1.00016     23.19000      1.07961      0.06234      1.07943      0.92641
           5      1.44561      1.44584      1.00016     23.03000      1.07216      0.06277      1.07199      0.93285
           6      1.44561      1.44584      1.00016     23.01000      1.07123      0.06283      1.07106      0.93366
           7      1.44561      1.44584      1.00016     22.98000      1.06983      0.06291      1.06966      0.93488
           8      1.44561      1.44584      1.00016     23.06000      1.07356      0.06269      1.07338      0.93163
           9      1.44561      1.44584      1.00016     23.03000      1.07216      0.06277      1.07199      0.93285
$ before=$(cat Noise | wc -c); for i in $(seq 1 19); do /bin/time -f "%e" -o /tmp/time zstd -$i -c < Noise | (wc -c > /tmp/after); time=$(cat /tmp/time); after=$(cat /tmp/after); echo $i $before $after $time; done | awk 'BEGIN { printf("%12s %12s %12s %12s %12s %12s %12s %12s %12s\n", "Level", "Size orig", "Size comp", "Size Factor", "Time (sec)", "Time (Factor)", "GB/sec", "Time2Size", "Size2Time") }  NR == 1 { fastest = $4 } { printf("%12d %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f %12.5f\n", $1, $2/(1024**3), $3/(1024**3), $3/$2 ,$4, $4/fastest, $2/$4/(1024**3), ($4/fastest)/($3/$2), ($3/$2)/($4/fastest)) }'
       Level    Size orig    Size comp  Size Factor   Time (sec) Time (Factor)       GB/sec    Time2Size    Size2Time
           1      1.44561      1.44564      1.00002      0.43000      1.00000      3.36188      0.99998      1.00002
           2      1.44561      1.44564      1.00002      0.36000      0.83721      4.01558      0.83719      1.19447
           3      1.44561      1.44564      1.00002      0.50000      1.16279      2.89122      1.16276      0.86002
           4      1.44561      1.44564      1.00002      0.47000      1.09302      3.07576      1.09300      0.91491
           5      1.44561      1.44564      1.00002      0.69000      1.60465      2.09508      1.60461      0.62320
           6      1.44561      1.44564      1.00002      0.72000      1.67442      2.00779      1.67438      0.59724
           7      1.44561      1.44564      1.00002      0.74000      1.72093      1.95352      1.72089      0.58109
           8      1.44561      1.44564      1.00002      0.91000      2.11628      1.58858      2.11623      0.47254
           9      1.44561      1.44564      1.00002      1.10000      2.55814      1.31419      2.55808      0.39092
          10      1.44561      1.44564      1.00002      1.57000      3.65116      0.92077      3.65108      0.27389
          11      1.44561      1.44564      1.00002      1.59000      3.69767      0.90919      3.69759      0.27045
          12      1.44561      1.44564      1.00002      2.51000      5.83721      0.57594      5.83708      0.17132
          13      1.44561      1.44564      1.00002      6.33000     14.72093      0.22837     14.72059      0.06793
          14      1.44561      1.44564      1.00002     13.55000     31.51163      0.10669     31.51091      0.03174
          15      1.44561      1.44564      1.00002     13.08000     30.41860      0.11052     30.41791      0.03288
          16      1.44561      1.44564      1.00002     88.06000    204.79070      0.01642    204.78601      0.00488
          17      1.44561      1.44564      1.00002    169.35000    393.83721      0.00854    393.82819      0.00254
          18      1.44561      1.44564      1.00002    174.85000    406.62791      0.00827    406.61860      0.00246
          19      1.44561      1.44564      1.00002    273.76000    636.65116      0.00528    636.63659      0.00157
$

 

[Krik]

Lz4 ist ab Level 3 schnarchlangsam. Es fällt von 1,7+ GB/s auf 65-66 MB/s. Irgendwie merkwürdig. Sicher, dass da nicht irgendwas das Ergebnis verfälscht hat?
So wie ich das sehe, ist Zstd hier der Sieger. Es komprimiert zwar nicht besser als die anderen Algorithmen, aber es ist bei den geringeren Leveln deutlich schneller.

Auch bei den Ergebnissen oben im Post #34 ist Zstd meist in Geschwindigkeit und Komprimierung überlegen. Erst ab Level 6 ist es langsamer, dafür zeigt es durchweg eine bessere Komprimierung.
Der Geschwindigkeitsabfall bei Lz4 ab Level 3 ist hier auch zu sehen. Ich nehme an, der Algorithmus schraubt hier deutlich an seinen Einstellungen.

Gzip komprimiert besser als Lz4, aber ist vergleichsweise sehr langsam. Eigentlich steht das nicht in Konkurrenz mit Lz4 und Zstd.


Ich habe mich nun auf .tar.std als mein Standardarchiv festgelegt. Nach und nach werde ich meine Backups darauf umändern.

 

[foofoobar]

Lz4 ist ab Level 3 schnarchlangsam. Es fällt von 1,7+ GB/s auf 65-66 MB/s. Irgendwie merkwürdig. Sicher, dass da nicht irgendwas das Ergebnis verfälscht hat?

Du kannst das gerne mit eigenen Daten oder weiteren Varianten testen, wenn sich da Abweichungen zeigen kann man weiter prüfen.

Allerdings zeigt sich ein ähnlicher Einbruch auch bei den gut komprimierbaren Daten.