[El Tocho]

Hey

ich begann kürzlich mich in die Entwicklung mobiler Apps für Android einzuarbeiten, als Entwicklerumgebung nutze ich hierzu das Android Studio von Google. Heute kam ich zufällig dazu einen Projektordner komplett auf eine externe Festplatte zu kopieren, hierbei fiel mir auf, dass die Kopiergeschwindigkeit über die Maßen langsam war.
Ich nutze bereits seit Jahren Visual Studio, komme aber selten dazu ganze Projektordner zu kopieren, weshalb ich nicht sicher war ob es hier ebenfalls so war, also testete ich es. Bei meinen Tests fiel mir auf, dass neben dem Kopieren sogar das Löschen (was ja selbst bei Gigabyte großen Datenmengen für gewöhnlich "Augenblicklich", also innerhalb einer für den menschen kaum/nicht wahrnehmbarer Zeit geschieht) eine ganze Weile dauerte

Ich kam insgesamt auf folgende Ergebnise:
Kopieren "normaler" Dateien: 100-120Mbyte/s
Kopieren eines Android Studio Projekt Ordners: 0,5-5MByte/s
Kopieren eines Visual Studio Projekt Ordners: 5-10MByte/s
Löschen eines Ordners mit diversen "normalen" Dateien(9GByte): wenige hundert ms
Löschen eines Android Studio Projekt Ordners(50MByte): 6s
Löschen eines Visual Studio Projekt Ordners(45MByte): 2s

Die oben angegebenen Daten entstammen alle derselben verbauten SSD, das Kopieren erfolgte hier innerhalb der gleichen SSD. Getestet habe ich das ganze aber auch auf verschiedenen anderen Datenträgern und mit diversen Testdaten, ebenso hab ich auch das Kopieren von einem Datenträger auf einen anderen getestet. Die Werte an sich variierten zwar, allerdings wurde jedesmal der gleiche sehr große Geschwindigkeitsunterschied deutlich.

Mir ist klar, dass diese Geschwindigkeiten durchaus variieren können, aber die Unterschiede der Zeiten/Geschwindigkeiten bei Projektordnern im Gegensatz zu diversen TestDatenmengen ist einfach utopisch hoch.
Ist das normal, hat jemand ähnliche Erfahrungen gemacht?
Und wenn ja, könnte mir jemand grob erklären wie es zu diesem Phänomen kommt? Kann mir leider selbst keinen Reim darauf machen.

mfg
Nicole

[Lookbehind]

tl;dr:
Viele kleine Dateien, killen die Performance bedeutend stärker als wenige große. Die Anzahl liegt da oft deutlich stärker in der Waagschale als die Gesamtgröße.
tl;dr-Ende


Eine große Datei von 9GB löschen bedeutet, der Rechner muss einen Eintrag aus der Dateisystem-Tabelle raus schmeißen. Das wird zwar vermutlich ein paar hundert Rechenschritte brauchen, aber bei heutigen CPU-Geschwindigkeiten und den dazugehörigen IO/s der Datenträger, ist das eher ein akademisch relevanter Wert.

450.000 Dateien zu je 2kB ergeben zusammen auch 9GB Datenvolumen. Um die zu löschen, müssen aber 450.000 Einträge im Dateisystem gesucht und gelöscht werden. Zudem hat kein Mensch wirklich 450.000 Dateien in einem Verzeichnis. Darum müssen die ganzen Unterverzeichnisse, und das werden ein paar hundert sein, vermutlich auch mit gelöscht werden. Das sind noch mal n Schwung Dateisystem-Einträge mehr, die auch noch an Bedingungen hängen, nämlich, dass nix mehr drin ist.
Auch hier dauert jede einzelne Dateisystem-Operation zwar nur einige hundert Rechenschritte, aber in der Masse, macht sich das doch enorm bemerkbar. Insbesondere weil hier in der Regel nicht die CPU-Geschwindigkeit, oder der pure Datendurchsatz der Festplatte die limitierenden Faktoren sind, sondern die IO/s (Input/Output-Operationen pro Sekunde) der Festplatte. Gegebenenfalls limitiert der verwendete Anschluss noch weiter. Ideal wäre in dem Fall eine PCIe SSD. Aber die meisten hängen an SATA. Per USB wirds ganz grausig.

Ein weiterer Effekt ist, dass die meisten Betriebssysteme ihre Anwender anlügen, was die wirkliche Übertragungsrate zur Festplatte angeht. Oft werden die Daten nämlich überhaupt nicht direkt auf die Platte geschrieben, sondern erstmal nur im RAM gesammelt. Das geht schön schnell und man kann dem Benutzer erzählen der Speichervorgang wäre fertig. Außerdem muss man so nicht die Platte für jeden Furz aus dem Schlaf holen, und die gerade anderweitig gebrauchte CPU-Power fürs Speichern von irgendwelchen Kleinigkeiten verbraten. Wenn sich dann irgendwann mal genug an zu speichernden Daten gesammelt hat, und gerade ein bisschen Zeit in der CPU übrig ist, speichert man das dann wirklich auf die Platte. Dem User fällt das in der Regel nicht auf, weil das meist nur einige Sekunden sind. (Ausnahme: Der berühmte, zu früh raus gezogene USB-Stick, aber da erkennen viele dann den Zusammenhang nicht. Da kann man noch so oft predigen, dass man USB-Sticks vorher sauber aushängen soll.)
Das Kopieren/Verschieben/Löschen einiger weniger Dateien, kann dann in der Regel einfach im RAM stattfinden. Fertig. Schneller als du gucken kannst. Aber wenns zu viele werden, geht das irgendwann nicht mehr im RAM/Cache. Dann muss wirklich mal direkt auf die Platte geschrieben werden. Und dann bekommt der User erstmals zu spüren, wie langsam die wirklich ist.

[foobar]

Hinzu kommt, dass die meisten halbwegs modernen Dateisysteme (inkl. NTFS) einen B-Tree als zentrale Verwaltungsstruktur haben. Einfügen und noch mehr Löschen sind bei diesen Bäumen vergleichsweise aufwendige Operationen, da ggf. sichergestellt sein muss, dass der gesamte Unterbaum nachher noch balanciert ist. Das ist halt der Preis, mit dem man sich die schnellere Suche bei diesen Bäumen erkauft. Und es macht Sinn, denn im Alltag sind die meisten Operationen eben Suchen. Einfügen und Löschen sind, im Verhältnis, eher Ausnahmen.

Wenn man also viele Dateien in vielen Verzeichnissen und Unterverzeichnissen löscht, muss auch der Baum entsprechend heftig beackert werden. Könnte mir schon vorstellen, dass sich das bei hinreichend vielen Operationen auch spürbar zusammen läppert.

[El Tocho]

Ok das macht Sinn, danke euch