Forum: PC Hard- und Software Suche Tool um Wirkung der NTFS Kompression abschätzen zu können


von Nano (Gast)


Lesenswert?

Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten 
abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine 
NTFS Kompression tatsächlich durchzuführen?

Ein Ansatz für so ein Tool könnte bspw. sein zwischen den Dateitypen zu 
unterscheiden.
Bereits komprimierte Dateien, wie bspw. PNG, ZIP, JPG usw. sind schon 
gut komprimiert, da ist kein nennenswerter Speicherplatzgewinn zu 
erwarten, aber andere Daten sind das nicht.
Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen.

Ich würde gerne gezielt herausfinden, bei welchen Ordnern meines Systems 
sich eine Kompression lohnen könnte.

von Oliver S. (oliverso)


Lesenswert?

Für ein paar Euro fünfzig gibts eine größere Festplatte.

Oliver

von Peter M. (r2d3)


Lesenswert?

Nano schrieb:
> Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen.

Du brauchst eine Tabelle mit empirischen Kompressionsraten zum 
abschätzen, die für jeden empirisch erfassten Dateityp Kompressionsraten 
liefert.

Dann listet Du einfach die Zieldateien auf und berechnest die erwarteten 
komprimierten Dateigrößen.

Du musst lediglich einmal Deine Tabelle mit für Dich repräsentativen 
Daten füttern.
Dafür musst Du einmal die Dateilängen eines Laufwerks oder Ordners 
erheben, die Kompression anstoßen und dann die neuen Dateilängen 
auslesen und im Folgenden die empirischen Kompressionsraten berechnen.

von oszi40 (Gast)


Lesenswert?

Treesize? Zeigt Speicherfresser. Ganz allgemein würde ich auf 
zusätzliche Kompression verzichten, da es nur eine weitere Fehlerquelle 
darstellt!

von Peter M. (r2d3)


Lesenswert?

Vor allem ist die NTFS-Kompression ein wunderbares Mittel zur
Fragmentierung des Laufwerks, was die Wiederherstellungschancen bei 
einem Datenunfall wunderbar herabsetzt.

von Tippse (Gast)


Lesenswert?

Nano schrieb:
> Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten
> abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine
> NTFS Kompression tatsächlich durchzuführen?

Dazu nimmt man einen schwachen aber auf Durchsatz optimierten Packer und 
komprimiert damit testweise. Zeigen sich bei einigen Dateien bei diesem 
durchlauf schon relativ starke Packraten geht da i.d.R. mit einem 
'richtigen' Packer oder schärfer eingestellten Werten noch mehr.

Da aber NTFS auch nur eines dieser auf Durchsatz optimierten Verfahren 
anwendet kannst du es auch gleich durch die NTFS-Komprimierung jagen.

zstd ist relativ neu und hat noch höheren Durchsatz als das was NTFS 
verwendet, damit kannst du dann schon eine gute und schnelle 
Vorabschätzung machen.
Wenn du dann noch entspr. Dateien ausklammerst die sowieso schon 
'gepackt' sind wie jpegs,... dann geht das recht flott, je nach 
Datenmenge die du vorliegen hast. Der Zeitaufwand entspricht dann der 
Zeit als würdest du die ganzen Daten umkopieren, id.R. sogar schneller, 
wenn du die gepackten Versionen auf einem separaten LW ablegst gehts 
noch fixer, musst ja nicht jedes File aufheben, dich interessiert nur 
die Grösse die speicherst du ab, die gepackte Datei verwirfst du nach 
dem Packen.

von Nano (Gast)


Lesenswert?

Peter M. schrieb:
> Nano schrieb:
>> Vielleicht gibt es auch einen anderen Ansatz das vorher abzuschätzen.
>
> Du brauchst eine Tabelle mit empirischen Kompressionsraten zum
> abschätzen, die für jeden empirisch erfassten Dateityp Kompressionsraten
> liefert.
>
> Dann listet Du einfach die Zieldateien auf und berechnest die erwarteten
> komprimierten Dateigrößen.
>
> Du musst lediglich einmal Deine Tabelle mit für Dich repräsentativen
> Daten füttern.
> Dafür musst Du einmal die Dateilängen eines Laufwerks oder Ordners
> erheben, die Kompression anstoßen und dann die neuen Dateilängen
> auslesen und im Folgenden die empirischen Kompressionsraten berechnen.

Ja, so etwas könnte ich natürlich implementieren.
Was mich aber noch interessiert ist, ob es ein Tool gibt, das über die 
Dateien drübergeht und dann im Vorfeld, ohne Schreibzugriffe, abschätzt 
wie gut die Datei komprimierbar ist.
Das Tool könnte bspw. schauen wie viele Muster vorkommen, die dann 
wiederum gut komprimierbar sind. Bereits komprimierte Dateiformate 
könnte es natürlich im Vorfeld ignorieren, bei diesen wird nicht viel zu 
gewinnen sein.

von Nano (Gast)


Lesenswert?

oszi40 schrieb:
> Treesize? Zeigt Speicherfresser.

Ja, es zeigt aber auch die dicken fetten H.264 Videodateien und die sind 
schon komprimiert.

> Ganz allgemein würde ich auf
> zusätzliche Kompression verzichten, da es nur eine weitere Fehlerquelle
> darstellt!

Ich wollte sie nur auf die Dateien von Programmen anwenden, wenn es da 
einen Fehler gibt, kann ich die leicht neu installieren.

von Peter M. (r2d3)


Lesenswert?

Hallo Nano,

diese von Dir beschriebene Abschätzung reicht vom Aufwand her schon an 
die Kompression heran.
Ich frage mich schon, wo da die Problemlage ist, die eine solche Lösung 
nahelegt, anstatt die Festplatte durch eine größere zu ersetzen. :)

von Nano (Gast)


Lesenswert?

Peter M. schrieb:
> Vor allem ist die NTFS-Kompression ein wunderbares Mittel zur
> Fragmentierung des Laufwerks, was die Wiederherstellungschancen bei
> einem Datenunfall wunderbar herabsetzt.

Meine eigenen Daten sind auf einer anderen Partition, wenn etwas 
aufgrund der Kompresion später schief laufen sollte, dann ist das nicht 
so schlimm. Außerdem habe ich noch Backups.
Es geht eigentlich nur um die Partition bei der ich Software 
installieren möchte.

von Peter M. (r2d3)


Lesenswert?

Nano schrieb:
> Es geht eigentlich nur um die Partition bei der ich Software
> installieren möchte.

Ach verstehe, Du möchtest einfach nur faul sein... Ok. :)

Der ganze Sums an ausführbarem Code ist doch komprimierbar (exe,dll etc) 
und ini-Dateien noch mehr, da reicht doch ein Mustertest per Hand an 
ausgewählten Exemplaren.

von Nano (Gast)


Lesenswert?

Tippse schrieb:
> Nano schrieb:
>> Gibt es ein Tool, das alle Ordner durchgeht und anhand der Daten
>> abschätzen kann, ob sich eine Kompression lohnt oder nicht, ohne eine
>> NTFS Kompression tatsächlich durchzuführen?
>
> Dazu nimmt man einen schwachen aber auf Durchsatz optimierten Packer und
> komprimiert damit testweise. Zeigen sich bei einigen Dateien bei diesem
> durchlauf schon relativ starke Packraten geht da i.d.R. mit einem
> 'richtigen' Packer oder schärfer eingestellten Werten noch mehr.
>
> Da aber NTFS auch nur eines dieser auf Durchsatz optimierten Verfahren
> anwendet kannst du es auch gleich durch die NTFS-Komprimierung jagen.

Für beides sind Schreibzugriffe notwendig und beides ist somit nicht in 
der Lage, das im Vorfeld abzuschätzen.
Laut Wikipedia verwendet NTFS den LZNT1 Kompressionsalgorithmus.
Ich bräuchte eigentlich nur eine Software, die den LZNT1 halber, also in 
so einer Art Vorlauf anwendet um dann das zu erwartende 
Kompressionsgewinn bei der gegebenen Datei abzuschätzen, gesetzt den 
Fall, das man das bei diesem Algorithmus so machen könnte.
Die Huffman-kodierung ermittelt bspw. zu Beginn die Häufigkeit einer 
Zeichenfolge, ab hier könnte man schon abschätzen, was zu erwarten ist, 
ohne die Kompression zu vollenden. Wenn ähnliches bei LZNT1 
funktioniert, dann wäre das ein Anfang.


> zstd ist relativ neu und hat noch höheren Durchsatz als das was NTFS
> verwendet, damit kannst du dann schon eine gute und schnelle
> Vorabschätzung machen.

Ich bin mir nicht so sicher ob es eine gute Idee ist, ein anderes 
Kompressionsverfahren dafür zu nutzen.
Einmal komprimiert das ganz anders, als bei LZNT1 zu erwarten wäre, 
womit die Aussagen mit Vorsicht zu genießen sind und zum anderen werde 
ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten 
komprimieren möchte. Windows muss also in der Lage sein diese bei Bedarf 
selber zu dekomprimieren.

von Nano (Gast)


Lesenswert?

Peter M. schrieb:
> Nano schrieb:
>> Es geht eigentlich nur um die Partition bei der ich Software
>> installieren möchte.
>
> Ach verstehe, Du möchtest einfach nur faul sein... Ok. :)
>
> Der ganze Sums an ausführbarem Code ist doch komprimierbar (exe,dll etc)
> und ini-Dateien noch mehr, da reicht doch ein Mustertest per Hand an
> ausgewählten Exemplaren.

Es geht mir mehr um die Nutzdaten der Programme.
Eine EXE zu komprimieren bringt fast nichts, da die oft eh nur wenige kB 
groß sind.
Die Leveldaten von bspw. dem Computerspiel Ark brachten aber gleich 40 
GB an Ersparnis, da lohnt sich der Aufwand.
Diese Dateien zu finden, das möchte ich automatisiert mit einem 
entsprechenden Tool erreichen.

von Karl (Gast)


Lesenswert?

Nano schrieb:
> Es geht eigentlich nur um die Partition bei der ich Software
> installieren möchte.

Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor 
dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine 
große Platte bzw. gleich SSD.

von oszi40 (Gast)


Lesenswert?

Nano schrieb:
> und zum anderen werde ich ohnehin die NTFS Kompression nutzen müssen

Kannst Du alles machen. Überlege bitte auch, wie schön DU dann 
fehlerhafte Daten erkennst und reparieren kannst.

von Nano (Gast)


Lesenswert?

Peter M. schrieb:
> Ich frage mich schon, wo da die Problemlage ist, die eine solche Lösung
> nahelegt, anstatt die Festplatte durch eine größere zu ersetzen. :)

Das ist geplant, es wird allerdings eine M.2 SSD. Bis dahin wollte ich 
bei meiner Programmpartition durch entsprechendes Dateimanagement mir 
etwas Platz verschaffen.

von Nano (Gast)


Lesenswert?

Karl schrieb:
> Nano schrieb:
>> Es geht eigentlich nur um die Partition bei der ich Software
>> installieren möchte.
>
> Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor
> dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine
> große Platte bzw. gleich SSD.

Ja, das macht Sinn. Weil die CPU bei diesem leichtgewichtigen 
Kompressionsverfahren die Daten schneller entpacken kann, als die 
Festplatte oder SSD die Daten liefern kann.
Ob's bei einer M.2 SSD anders aussieht, die kann die Daten ja deutlich 
schneller liefern, müsste man mal messen.

von Sturm88 (Gast)


Lesenswert?

Karl schrieb:
>
> Macht es in Hinsicht auf Performance überhaupt Sinn? Dann muss ja vor
> dem Laden der Programme erst noch entpackt werden. Dann doch lieber eine
> große Platte bzw. gleich SSD.

Natürlich macht das Sinn - schau Dir mal ZFS an!
Das setzt natürlich einen über Windows hinausgehenden Horizont voraus

von Thomas (Gast)


Lesenswert?

Naja, er will ja nur abschätzen.

Ich schätze mal.... ca. 1/3 der ursprünglichen größe.

Wer schätzt mit?

von Peter M. (r2d3)


Lesenswert?

Hallo oszi40,

oszi40 schrieb:
> Kannst Du alles machen. Überlege bitte auch, wie schön DU dann
> fehlerhafte Daten erkennst und reparieren kannst.

wie reparierst Du fehlerhafte Daten?

von Nano (Gast)


Lesenswert?

Thomas schrieb:
> Naja, er will ja nur abschätzen.
>
> Ich schätze mal.... ca. 1/3 der ursprünglichen größe.
>
> Wer schätzt mit?

Du sollst auch die Dateien und Ordner benennen.

Abzuschätzen was eine Kompression kann, ist keine Leistung, das ist 
bekannt.

von oszi40 (Gast)


Lesenswert?

Von der Statistik her werden wohl die meisten Platzfresser schon 
komprimiert herumliegen? Instatllationsprogramme sind auch oft gepackt. 
Die paar .txt könnten zwar auf 10% komprimiert werden, wird aber 
gegenüber komprimierten Videos kaum Platzgewinn erreichen, sondern eher 
Zeit kosten. Meine Meinung weiterhin: Aufwand>Nutzen. Größere Platte 
beschaffen und Image machen. Alte Platte als Backup in den Schrank 
legen.

von Klaus P. (Gast)


Lesenswert?

Nano schrieb:
> Ein Ansatz für so ein Tool könnte bspw. sein zwischen den Dateitypen zu
> unterscheiden.
> Bereits komprimierte Dateien, wie bspw. PNG, ZIP, JPG usw. sind schon
> gut komprimiert, da ist kein nennenswerter Speicherplatzgewinn zu
> erwarten, aber andere Daten sind das nicht.

Eion fertiges Tool kenne ich nicht, ist mit C# aber recht schnell selbst 
erstellt.

Einfach die Verzeichnisse rekursiv durchgehen und die Dateigröße der 
betreffenden Dateien aufsummieren. Dabei Dateien, die kleiner als die 
Blockgröße des Filesystems sind, ggf. nicht berücksichtigen.

Ansatz z.B. hier: 
https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.getfiles?view=netframework-4.8

von Nano (Gast)


Lesenswert?

oszi40 schrieb:
> Meine Meinung weiterhin: Aufwand>Nutzen.

Am Ark Beispiel sieht man ja, dass der Nutzen groß sein kann. 40 GB 
kriegt man auch mit der günstigsten SSD nicht für lau.

Und den Aufwand möglichst gering zu halten, darüber handelt ja der 
Thread.
Wenn man die Daten nicht Testkomprimieren muss, weil man einen Weg 
gefunden hat, das im Vorfeld abzuschätzen, dann hat man schon einmal den 
Aufwand verringert, ebenso, wenn man bereits komprimierte Dateien und 
Ordner herausfiltert.

Aber ich sehe schon, dass noch kein Tool genannt wurde zeigt, dass es 
wohl keines gibt und ich da etwas selber programmieren muss.

von Walter T. (nicolas)


Lesenswert?

Einfachste Lösung:

1. Besorgt Dir eine USB-Platte.
2. Formatiere sie NTFS komprimiert.
3. Schiebe die Daten darauf, von denen Du wissen willst, wie gut sie 
sich komprimieren lassen.
4. Profit.

: Bearbeitet durch User
von Berufsberater (Gast)


Lesenswert?

Nano schrieb:
> ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten
> komprimieren möchte.

Ja eben, merkst du was? Dein Vorhanben ist wie "wasch mir den Pelz aber 
mach mich nicht nass". Wenn du genaue Abschätzungen haben willst musst 
du es durch die NTFS-Komprimierung jagen, also ist dein Vorhaben Unsinn 
je genauer die Abschätzung werden soll und kannst gleich alles 
komprimieren, mit nem groben Dateitypfilter der Files wie zip, rar, 
png,... auslässt.

von Walter T. (nicolas)


Lesenswert?

Ich finde die Frage, wieviel das überhaupt bringt, durchaus berechtigt, 
bevor ich irgendwelche Modifikationen an meiner Systempartition 
vornehme.

von Nano (Gast)


Lesenswert?

Berufsberater schrieb:
> Nano schrieb:
>> ich ohnehin die NTFS Kompression nutzen müssen, da ich ja Programmdaten
>> komprimieren möchte.
>
> Ja eben, merkst du was? Dein Vorhanben ist wie "wasch mir den Pelz aber
> mach mich nicht nass". Wenn du genaue Abschätzungen haben willst musst
> du es durch die NTFS-Komprimierung jagen, also ist dein Vorhaben Unsinn
> je genauer die Abschätzung werden soll und kannst gleich alles
> komprimieren, mit nem groben Dateitypfilter der Files wie zip, rar,
> png,... auslässt.

Oben habe ich alles Dau gerecht erklärt, es ist nicht schlimm, wenn man 
am Anfang Rückfragen hat, aber wenn man dann immer noch nicht verstanden 
hat, worum es eigentlich geht, dann sollte man besser Schweigen, anstatt 
so ganz arrogant auf Stammtischniveau Sätze wie "Merkst du was" 
rauszuhauen.

Man sieht jedenfalls, dass du von Algorithmen, Programmieren und 
Computer nicht viel Ahnung haben kannst, deswegen halt Stammtischniveau 
mit Halbwissen.
Ich erkläre dir daher das, was ich oben schon gesagt habe, also jetzt 
extra für dich zum n-ten mal:

Es geht um folgendes.
Wenn du 1000 Einsen als Folge hast, dann musst du da keinen 
Kompressionsalgorithmus vollständig drüberlaufen lassen um zu wissen, 
dass das gut komprimierbar ist, das siehst du schon so im 
Anfangsdurchlauf.
Das gleiche bei einem Textstring wie "HalloHalloHallo", das Wort kommt 
dreimal vor, also wird man es gut komprimieren können.

Ein Kompressionsalgorithmus ist keine atomic Operation, okay, das weißt 
du wahrscheinlich wieder nicht, was das in der Informatik bedeutet, also 
muss ich länger ausholen.
Es bedeutet im Prinzip, das bspw. aus A B wird und das vollständig und 
wenn der Prozess nicht abgeschlossen werden konnte, das alles wieder 
zurückgerollt oder verworfen wird.
Ein Kompressionsalgorithmus besteht aus mehreren Schritten, nennen wir 
sie mal 1, 2, 3, 4, 5 bis n und um zu wissen, ob etwas gut Komprimierbar 
ist, muss man nicht alles vollständig bis Schritt n durchlaufen lassen, 
wie du mit deinem Halbwisen behauptest, sondern du kannst je nach 
Algorithmus bei 1 oder 2 schon abbrechen und damit sparst du sehr viel 
Rechenzeit.

Um also mal dein Pelz Beispiel zu bleiben.
Es sei gegeben zwei Bären.
Bär A hat sich im Dreck gewälzt.
Bär B hat sich nicht im Dreck gewälzt.

Von uns beiden bisst du jetzt derjenige, der den Eimer nimmt und für Bär 
A und Bär B eine vollständige Wäsche mit schruppen, viel Wasser und 
allem macht.
Ich dagegen schau mir erstmal nur den Pelz von A und B an.
A wasche ich mit Wasser, den Bär mach ich nass, weil ich sehe, dass der 
Pelz dreckig ist.
Beim Bär B breche ich nach dem anschauen des Pelzes ab, da komme ich 
erst gar nicht zum Schritt "Bär waschen", denn der Bär ist sauber.

Und so wie es da ist, so kann man das auch mit Daten machen.

Oben habe ich z.B. gesagt, man kann alle Dateien die ein Dateiformat 
haben, das selbst schon komprimiert, ignorieren kann.
Auch dieses Ansehen, "ist Datei bild.jpg im JPEG Format?" ist schon ein 
Schritt, der Schritt ist zwar nicht Teil eines Kompressionsalgorithmus, 
aber er könnte sehr wohl Teil eines Programmes sein, dass die Dateien 
nach deren Kompriebnierbarkeit zusammensucht.
Nach dem klar ist, dass man es nicht weiter zu untersuchen braucht, wird 
für diese Datei jeder weitere folgende Schritt abgebrochen.

Bei eine Datei unbekannten Dateityps könnte man dann einen groben 
"Gucken" drüberlauf machen, was dem obigen Beispiel für den Gedachten 
Kompressionsalgorithmus nicht 1 bis Schritt n ist, sondern eben 
vielleicht nur bis Schritt 2.

Soviel zu diesem Punkt.
Und was den Satz betrifft, den du von mir zitiert hast, geht es bei dem 
um einen ganz anderen Kontext, nämlich das was ganz am Schluss, nach dem 
Durchchecken kommen muss, nämlich dass, wenn Komprimiert werden muss, 
wegen NTFS, sowieso die Kompression von NTFS benutzt werden muss.
Also bist du mit deiner arroganten Antwort "Merkst du was" auf dem 
völlig falschen Dampfer und merkst es nicht einmal.

von Irgendwer (Gast)


Lesenswert?

Walter T. schrieb:
> bevor ich irgendwelche Modifikationen an meiner Systempartition
> vornehme.

Um einzelne Dateien in einem NTFS-Filesystem zu komprimieren brauchst du 
an deiner Systempartition überhaupt nichts dran rumzumodifizieren. Das 
ganze kann gezielt pro Datei oder Verzeichnis jederzeit ein und 
ausgeschaltet werden.

von FS (Gast)


Lesenswert?

Soweit ich weiß, ist die NTFS-Kompression sowohl vom Algorithmus als 
auch von der Performanz her nichts besonderes, da diese sicherlich auf 
Verlässlichkeit und Datenintegrität optimiert ist und damit nur 
durchschnittlich schnell sein dürfte. Ich meine, in einem Blogartikel 
von Raymond Chen (Microsoft Windows-Entwickler) mal etwas zu dem Thema 
gelesen zu haben, ist aber schon eine Weile her. Das würde zumindest 
auch erklären, warum man u.a. bei ReFS darauf verzichtet hat. Ich wüsste 
auch nicht, warum man aktiv genutzte lokale Dateien in der heutigen Zeit 
komprimieren sollte. Vor allem, wenn diese eine gewisse Größe erreichen 
(GB+), denn dann kommt für jeden Lesezugriff auch immer der CPU-Overhead 
für die Dekompression ins Spiel. Caches und RAM sind hier die Grenze, 
werden viele Daten nachgeladen und müssen andere dafür aufgrund 
mangelndem Speicher wieder freigegeben werden wirkt sich das sicherlich 
auf die Geschwindigkeit aus. Bei vielen Schreibzugriffen macht es noch 
weniger Sinn.

Ich halte von der NTFS-Kompression nicht viel, die taugt allenfalls für 
Archivierungszwecke selten genutzer Dateien.

von Nano (Gast)


Lesenswert?

FS schrieb:
> Ich wüsste
> auch nicht, warum man aktiv genutzte lokale Dateien in der heutigen Zeit
> komprimieren sollte. Vor allem, wenn diese eine gewisse Größe erreichen
> (GB+), denn dann kommt für jeden Lesezugriff auch immer der CPU-Overhead
> für die Dekompression ins Spiel. Caches und RAM sind hier die Grenze,
> werden viele Daten nachgeladen und müssen andere dafür aufgrund
> mangelndem Speicher wieder freigegeben werden wirkt sich das sicherlich
> auf die Geschwindigkeit aus.

Eine Festplatte ist im Laden der Daten langsamer, als sie eine moderne 
CPU dekomprimieren kann.
Da reicht schon ein grober Blick auf den Datendurchsatz einer Festplatte 
und ein Vergleich mit der Bandbreite des RAM.
Eine 4 TB Festplatte schafft vielleicht etwa 200 MB/s (so als Richtwert, 
hab's nicht gemessen)
Die Bandbreite des RAMs liegt bei DDR4-2133 RAM bei 17 GB/s im single 
Channel Betrieb.
Im Vergleich zur CPU ist RAM aber unglaublich langsam, weswegen man der 
CPU heutzutage mehrere Caches verpasst.

Wenn man jetzt weiß, dass eine CPU + Cache um ein vielfaches schneller 
ist, als Zugriffe auf das RAM, dann kann man auch als grobe 
Überschlagsrechnung die Annahme treffen, dass sie bei einfachen 
Kompressionsalgorithmen, wie sie bei NTFS verwendet werden, wesentlich 
schneller die Daten komprimieren und dekomprimieren kann, als der 
Controller der Festplatte die Daten von der Festplatte holen und ins RAM 
schieben kann. Denn das Nadelöhr ist hier ganz klar die Festplatte.
Wenn die Daten komprimiert vorliegen, dann geht theoretisch das Laden 
mit Kompression sogar schneller, weil dann die Festplatte nicht so viele 
Daten pro Sekunde zum RAM schieben muss.

Und die Praxis zeigt dann auch, dass da kaum ein Unterschied besteht.
Wobei bei diesem Test eine SSD verwendet wurde, deren Datendurchsatz ist 
deutlich höher als die einer Festplatte, so dass sich das, wie bereits 
gesagt, zugunsten der nicht Kompression etwas verschiebt, aber die 
Unterschiede sind bei einer SATA SSD vernachlässigbar klein:
https://www.tomshardware.com/reviews/ssd-ntfs-compression,3073-10.html

Und hier gibt es noch eine weitere Erklärung dazu:
https://superuser.com/questions/411720/how-does-ntfs-compression-affect-performance

Lediglich mit M.2 NVME SSDs kann es wieder anders aussehen, da diese 
sehr schnell Daten laden und ins RAM schieben kann.

> Ich halte von der NTFS-Kompression nicht viel, die taugt allenfalls für
> Archivierungszwecke selten genutzer Dateien.

Bei mir hat sie viel gebracht, siehe oben die Beispiele.
Und gerade bei Spielen, bei denen die Map nur einmal am Anfang ins RAM 
geladen werden muss, merkt man beim Spielen nichts mehr, denn die Daten 
sind dann ja schon lange im RAM.
Aber es muss halt jeder selber wissen ob er die Kompression nutzen 
möchte oder nicht.

Die NTFS Kompression kann man übrigens gezielt auf Dateien und Ordner 
anwenden, d.h. es ist kein alles oder nichts, sondern man kann ganz 
gezielt auswählen, was man komprimieren möchte und was nicht.
Ich mache das z.B. genau so.
Mein Windows Ordner ist bspw. komplett unkomprimiert, während der obige 
Ark Daten Ordner komprimiert ist und dessen EXE und DLL Dateien wiederum 
nicht.
Und damit ist auch klar, warum ich den Thread gestartet habe, mir geht 
es darum, gezielt die Ordner herauszufinden, wo es sich lohnt und der 
Aufwand es wert ist.
Wenn ich Speicherplatz im zweistelligen GB Bereich spare, dann nutze ich 
die Kompression auf einen Ordner jedenfalls gerne.

von Susi Sorglos (Gast)


Lesenswert?

Nano, Du hast Dich gut mit dem Thema Komprimierung beschäftigt. Es 
stimmt natürlich, daß eine komprimierte Datenmenge schneller durch einen 
Flaschenhals gelangt. Mir wäre Rosinenpickerei zu mühsam und das Risiko 
dabei einen Fehler zu machen, etwas zu hoch.

Nano schrieb:
> 40 GB kriegt man auch mit der günstigsten SSD nicht für lau.

1 TB heute ca. <120€ 
https://www.idealo.de/preisvergleich/OffersOfProduct/6220699_-ssd-plus-1tb-sandisk.html

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.