Mainboards, BIOS, Prozessoren, RAM 27.294 Themen, 124.102 Beiträge

Verfolgung starten Optionen

Wie schnell ist RAM bei kleinen Dateien?

Sovebämse / 19 Antworten / Baumansicht Nickles

Hallo zusammen

Da ja das Problem auch heute noch besteht, dass beim Lesen / Zugriff auf viele kleinere Dateien (wie z. B. beim Windows-Start etc.) selbst bei den SSDs noch eine riesige Diskrepanz herrscht zum Lesen grosser Dateien (Leistung im unteren einstelligen Prozentbereich, konkret so um 50 MB/s), wollte ich mal fragen, ob es diese krasse Diskrepanz eigentlich auch beim RAM gibt.

Zudem die Frage: Wird es in Zukunft mal möglich sein, das Lesen kleiner Dateien fast so schnell hinzukriegen wie das Lesen grosser Dateien? Was bräuchte es dazu noch und wie weit ist man schon auf dem Weg? Nehme an, da reden wir dan schon über den Quantencomputer bzw. diese Ebene der Technik.

Gruss und Dank
Thomas

bei Antwort benachrichtigen
pappnasen Sovebämse „Wie schnell ist RAM bei kleinen Dateien?“
Optionen

Das wird nie schneller werden.

Der Zeitaufwand wird für die Adressierung benötigt.

bei Antwort benachrichtigen
Sovebämse pappnasen „Das wird nie schneller werden. Der Zeitaufwand wird für die Adressierung benötigt.“
Optionen

Und weshalb kann die Adressierung nicht schneller werden?

bei Antwort benachrichtigen
Andreas42 Sovebämse „Wie schnell ist RAM bei kleinen Dateien?“
Optionen

Hi!

Das ist eine recht komplexe Sache. Versuchen wir es mal mir meinem Wissen zu betrachten (das ist allerdings auch nicht mehr 100% auf der Höhe der Zeit).

Ich bin mir mir ziemlich sicher, dass LESEN nicht das Problem ist, sondern SCHREIBEN. Warum, dazu kommen wir später.

Dann bin ich mir nicht sicher, ob beim Lesen große Dateien generell schneller geladen werden, als kleine. Das liegt einfach daran, dass bei einem Lesezugriff mindestens drei Leseoperationen laufen müssen:

1. Wir müssen die Datei im Verzeichnis finden
Über diesen Verzeichniseintrag finden wir dann auch die Stelle, wo der Dateiinhalt abgelegt ist.

2. Wir müssen den eigentlichen Dateiinhalt laden
Der liegt auf dem Datenträger, aber nicht direkt "neben" dem Verzeichniseintrag.

3. Eine Liste der von einer Datei belegten Sektoren muss geladen werden
Die Sektoren einer Datei liegen nicht hintereinander, deshalb kennen moderne Dateisysteme Verwaltungssektoren, welche die Reihenfolge der belegten Sektoren einer Datei enthalten.
Je größer die Datei ist, desto häufiger müssen diese Verwaltungssektoren gelesen werden.

Kleinere Dateien laden natürlich weniger dieser Verwaltungssektoren, dafür muss dann bei vielen kleinen Dateioen häufiger der Dateieintrag gesucht werden.

Was da jetzt schneller ist? Keine Ahnung. OK, man kann es nicht nur an diese ganz einfachen Dingen festmachen. Da kommen dann immer noch lese-Optimierung des Dateisystems und des Datenträgers hinzu, die im Hintergrund arbeiten (Stichwort Lese-Cache). Da wirken dann solche Dinge wie Imvoraus-Lesen mit. Das wird oft was bringen, kann dann aber in ungünstigen Fällen auch bewirken, das der Cache verworfen wird und neu geladen werden muss. Ich tippe, das wird bei vielen kleinen Dateien häufiger vorkommen, als bei wenigen Großen.

Beim SCHREIBEN kommt nur noch weitere Komplexität hinzu: erst lesen wir die ganzen Informationssektoren udn verzeichniss udn dann schreiben wir neue Information dort hinein. Beim Schreiben der Daten werden die alten Daten erst nach dem schreiben der neuen Daten i wieder freigegeben.
Aber das reicht noch nicht an zusätzlichen Aufwand: soweit ich weiß sind die physikalisch geschriebenen Einheiten (Cluster) häufig größer als ein Sektor. Je mehr Sektoren in einem Cluster liegen, desto mehr Schreiboperationen, kann man mit passenden Schreibcache einsparen - wenn das denn alles passt.
Das Problem ist, dass dies bei kleinen Dateien vermutlich nicht immer gut passen wird. Spätestens, wenn eine neue kleine Datei geschrieben wird, die in einen Cluster soll, der bereits kurz vorher geschrieben werden sollte und jetzt gerade gesperrt ist, bis der alte Inhalt geschrieben wird, muss das ganze Warten.

Bei modernen Festplatten, hab ich gehört, dass teilweise die Spuren komplett geschrieben werden müssen, weil die Information auf der Spur so eng liegt, dass man nicht mehr sauber dazwischen einfügen kann. Die nächste Steigerung sind dann Spuren, die so schmal sind, dass man sie nicht sauber trennen kann. Auch soetwas hat man technisch im Griff und nutzt das.

https://www.storage-insider.de/was-ist-shingled-magnetic-recording-smr-a-856848/

Das sollte natürlich bei SSDs nicht zutreffen, da man dort ja bekanntermaßen ohne rotierende Speicherchips auskommen muss. Zwinkernd

Aber SSDs sind beim Speichern auch keine Zauberer. Da müssen komplexere elektronische Vorgänge ablaufen, die Zeit brauchen.

https://www.computerweekly.com/de/feature/Grundlagen-Wie-Flash-Speicher-funktioniert

"Die Eigenschaften von NAND-Flash sind so beschaffen, dass ein einzelner Wert in einer Zelle von 1 zu 0 geändert werden kann. Das funktioniert allerdings nicht umgekehrt, ohne den gesamten Block neu formatieren zu müssen. Dieser Vorgang ist als P/E-Zyklus (Program-Erase Cycle) bekannt."

Soweit, so alt ist mein technisches Grundwissen auf dem Gebiet.

Frag mich jetzt bitte nicht nach weiteren Details. Auf dem Gebiet bin ich soweit, wie unser bekannter Kollege der sich hier schon seit Jahren mit der Sinnfrage beschäftigt, wie das mit den Nullen und Einsen in der CPU funktioniert.

Ich hoffe, dass Mitleser die verbliebenen Lücken füllen können (auch wenn sie dabei alles für Lötsinn erklären müssen, weil es eben altes Wissen war und dann noch einmal bei Bienchen und Bytes neu anfangen müssen)

Bis dann
Andreas

Hier steht was ueber mein altes Hard- und Softwaregedoens.
bei Antwort benachrichtigen
pappnasen Andreas42 „Hi! Das ist eine recht komplexe Sache. Versuchen wir es mal mir meinem Wissen zu betrachten das ist allerdings auch nicht ...“
Optionen

Die Prozesseorgeschwindigkeit hat damit auch zu tun.

bei Antwort benachrichtigen
gelöscht_189916 Andreas42 „Hi! Das ist eine recht komplexe Sache. Versuchen wir es mal mir meinem Wissen zu betrachten das ist allerdings auch nicht ...“
Optionen

Uff...

...ich stelle mir gerade einen Quantenrechner in der Bude vor. Das Hochhaus daneben dient dem Kühlen;-)

Irgendwann wird wahrscheinlich über KI der gewünschte Inhalt geladen, bevor man überhaupt weiss, dass man den wollte.

bei Antwort benachrichtigen
hatterchen1 gelöscht_189916 „Uff... ...ich stelle mir gerade einen Quantenrechner in der Bude vor. Das Hochhaus daneben dient dem Kühlen - Irgendwann ...“
Optionen
Irgendwann wird wahrscheinlich über KI der gewünschte Inhalt geladen, bevor man überhaupt weiss, dass man den wollte.

Das ist dann mal eine echte Innovation.
Weshalb soll der Mensch dem Rechenknecht sagen was er machen soll? Der soll gefälligst heute das machen, was uns morgen einfällt.Zwinkernd

Im Übrigen kann mein Rechner schneller lesen und schreiben als ich und das reicht mir.

Gruß

h1

Gestottertes Wissen ist besser als eloquente Dummheit. Marcus Tullius Cicero (106 - 43 v.Chr.Rom) Staatsmann und Philosoph
bei Antwort benachrichtigen
gelöscht_189916 hatterchen1 „Das ist dann mal eine echte Innovation. Weshalb soll der Mensch dem Rechenknecht sagen was er machen soll? Der soll ...“
Optionen
Im Übrigen kann mein Rechner schneller lesen und schreiben als ich und das reicht mir.


Die Diskussion bewegt sich vermutlich eher im ideellen Bereich. Zumindest ist die grosse Diskrepanz zwischen Lesen und Schreiben selbst bei SSD vermutlich nicht einmal zu spüren im PC-Alltag.

bei Antwort benachrichtigen
hatterchen1 gelöscht_189916 „Die Diskussion bewegt sich vermutlich eher im ideellen Bereich. Zumindest ist die grosse Diskrepanz zwischen Lesen und ...“
Optionen

Also ich merke nicht einmal den Unterschied zwischen SSD und NVMe mit quasi fünffacher Geschwindigkeit.
Und beim RAM werden kleinere Latenzen richtig teuer. Für mich sind das so Wolken-Kuckuks Diskussionen.

Wenn der Briefträger in einem Hochhaus, jeder Partei einen Brief zustellt, dauert das natürlich auch länger, als würde er die gleiche Menge Post dem Finanzamt in den Empfang stellen.

Wer das, im Zeitalter des Jedermann PCs, nicht begreift, der begreift wohl auch sonst nicht viel.

Gruß

h1

Gestottertes Wissen ist besser als eloquente Dummheit. Marcus Tullius Cicero (106 - 43 v.Chr.Rom) Staatsmann und Philosoph
bei Antwort benachrichtigen
Borlander hatterchen1 „Also ich merke nicht einmal den Unterschied zwischen SSD und NVMe mit quasi fünffacher Geschwindigkeit. Und beim RAM ...“
Optionen
Also ich merke nicht einmal den Unterschied zwischen SSD und NVMe mit quasi fünffacher Geschwindigkeit.

NVMe ist eine Schnittstelle zur Anbindung von SSDs, als für diesen Einsatzweck besser geeignete Alternative zu SATA/AHCI.

Wenn der Briefträger in einem Hochhaus, jeder Partei einen Brief zustellt, dauert das natürlich auch länger, als würde er die gleiche Menge Post dem Finanzamt in den Empfang stellen.

Wenn er alle Briefe in den ersten Briefkasten steckt und drauf vertraut, dass der Bewohner es an seine Nachbarn verteilt dann geht das ähnlich schnell :-P

bei Antwort benachrichtigen
Borlander hatterchen1 „Das ist dann mal eine echte Innovation. Weshalb soll der Mensch dem Rechenknecht sagen was er machen soll? Der soll ...“
Optionen
Im Übrigen kann mein Rechner schneller lesen und schreiben als ich und das reicht mir.

Der muss aber auch wesentlich mehr lesen und schreiben als Du um das gleiche Ergebnis zu erzielen.

bei Antwort benachrichtigen
Borlander Andreas42 „Hi! Das ist eine recht komplexe Sache. Versuchen wir es mal mir meinem Wissen zu betrachten das ist allerdings auch nicht ...“
Optionen

So ein paar Ergänzende Gedanken:

1. Wir müssen die Datei im Verzeichnis finden

U.U. müssen wir auch erst noch das Verzeichnis finden innerhalb eines Verzeichnisbaums. Dann wird dieser Vorgang sogar mehrfach notwendig.

3. Eine Liste der von einer Datei belegten Sektoren muss geladen werden Die Sektoren einer Datei liegen nicht hintereinander, deshalb kennen moderne Dateisysteme Verwaltungssektoren, welche die Reihenfolge der belegten Sektoren einer Datei enthalten. Je größer die Datei ist, desto häufiger müssen diese Verwaltungssektoren gelesen werden.

Moderne Dateisysteme nutzen heute auch Extends um zusammenhängende Sektoren kompakt abzubilden: Statt einer langen Liste mit Sektoren 500,501,502,...,999,1000,2000,2001,...,2999,3000 kann man das wesentlich kompakter als 500-1000,2000-3000 darstellen.

2. Wir müssen den eigentlichen Dateiinhalt laden Der liegt auf dem Datenträger, aber nicht direkt "neben" dem Verzeichniseintrag.

Bei NTFS werden sehr kleine Dateien (AFAIR liegt die Grenze bei etwa 1,4KB) tatsächlich direkt in der MFT abgespeichert.

Lese-Cache). Da wirken dann solche Dinge wie Imvoraus-Lesen mit. Das wird oft was bringen, kann dann aber in ungünstigen Fällen auch bewirken, das der Cache verworfen wird und neu geladen werden muss. Ich tippe, das wird bei vielen kleinen Dateien häufiger vorkommen, als bei wenigen Großen.

Bei Cache haben wir auch noch eine mehrstufige Hierarchie, selbst wenn der Zugriff aufs RAM erfolgt. Wenns noch nicht im L1, L2 oder L3 Cache liegt dann muss man Ende sogar aufs langsame RAM gewartet werden.

Beim Schreiben der Daten werden die alten Daten erst nach dem schreiben der neuen Daten i wieder freigegeben.

Das wäre das Verhalten was man bei Copy-On-Write-Dateisystemen vorfindet. Die sind zwar sehr robust, aber die hat man nicht immer (und die haben auch den Nachteil, dass sie die Fragmentierung begünstigen).

Aber das reicht noch nicht an zusätzlichen Aufwand: soweit ich weiß sind die physikalisch geschriebenen Einheiten (Cluster) häufig größer als ein Sektor. Je mehr Sektoren in einem Cluster liegen, desto mehr Schreiboperationen, kann man mit passenden Schreibcache einsparen - wenn das denn alles passt. Das Problem ist, dass dies bei kleinen Dateien vermutlich nicht immer gut passen wird. Spätestens, wenn eine neue kleine Datei geschrieben wird, die in einen Cluster soll, der bereits kurz vorher geschrieben werden sollte und jetzt gerade gesperrt ist, bis der alte Inhalt geschrieben wird, muss das ganze Warten.

Bei RAM haben wir erst mal keine Sektoren, aber die Organisation erfolgt in virtuellen Speicherseiten (heute i.d.R. 4KiB) die dann in Hardware auf physikalische Speicheradressen gemappt werden müssen.

Bei Festplatten haben wir heute ja die etwas krude Situation, dass sie nach außen meist immer noch die 512Byte Sektoren präsentieren, intern jedoch mit 4KiB Sektoren arbeiten. Willst Du da nur ein Bit ändern musst Du den kompletten Sektor neu schreiben (der u.A. auch ein bisschen Overhead wie Checksummen enthält). Bei Flash-Speichern hat man sogar noch größere zusammhängende Blöcke.

Gruß
bor

bei Antwort benachrichtigen
Sovebämse Borlander „So ein paar Ergänzende Gedanken: U.U. müssen wir auch erst noch das Verzeichnis finden innerhalb eines Verzeichnisbaums. ...“
Optionen

Nun, die Erklärungen zeigen, warum diese Prozesse bei mehreren, kleineren Dateien so lange dauern. Aber es sagt noch nicht, warum man genau bei diesen Prozessen es bis jetzt nicht geschafft hat, diese in ähnlichem Masse zu verschnellern wie man das beim Lesen grosser Dateien schaffen konnte.

bei Antwort benachrichtigen
Borlander Sovebämse „Nun, die Erklärungen zeigen, warum diese Prozesse bei mehreren, kleineren Dateien so lange dauern. Aber es sagt noch ...“
Optionen
warum man genau bei diesen Prozessen es bis jetzt nicht geschafft hat, diese in ähnlichem Masse zu verschnellern wie man das beim Lesen grosser Dateien schaffen konnte.

... die sind unabhängig von der Dateigröße. Bei großen Dateien ist deren Anteil nur vernachlässigbar klein. Siehe mein Beitrag unten.

bei Antwort benachrichtigen
Andreas42 Sovebämse „Nun, die Erklärungen zeigen, warum diese Prozesse bei mehreren, kleineren Dateien so lange dauern. Aber es sagt noch ...“
Optionen

Hi!

Ich habe noch einen anderen Erklärungsansatz, der darauf hinaus läuft, dass es einfach nicht geht.

Der Verwaltungsanteil ist bei großen und kleinen Datei immer der selbe. Und zwar reden wir jetzt von dem Vorgang, bis das Lesen der Daten beginnen kann. Auch das Lesen der eigentlichen Daten ist gleich schnell, weil grundsätzlich die selbe Technik im Hintergrund zum Einsatz kommt.

Klar ist dann, dass kurze Daten generell schneller gelesen werden als große: mehr Daten zu lesen braucht mehr Zeit.

Das bedeutet jetzt einfach, dass kleine Dateien immer schneller geladen werden als große.

Warum passt das nicht zu den Messwerten?

Weil diese die Zeit für die gesamte Dateioperation nehmen und mit der Größe der Datei verrechnen. Das ignoriert dann die durch die Verwaltung mitgelesene Datenmenge.

Man könnte jetzt einfach eine Messung vorsehen, die nur die Zeitdauer für das reine Lesen der Daten misst. Macht man aber nicht, weil sich dann jeder fragen würde, warum das Lesen von kleinen Dateien so lange dauert, obwohl die Lesegeschwindigkeit nicht eingebrochen, sondern sogar größer ist.

Da der Verwaltungsaufwand für alle Dateien gleich ist, kann er auch nicht für kleine Dateien verkürzt werden.

Die einzige Lösung wäre banal: kleine Dateien auf einen besonders schnellen Datenträger zu schreiben. Was aber unsinnig ist, da die großen Dateien natürlich auch von diesem schneller geladen werden.

Bis dann

Andreas

Hier steht was ueber mein altes Hard- und Softwaregedoens.
bei Antwort benachrichtigen
Sovebämse Andreas42 „Hi! Ich habe noch einen anderen Erklärungsansatz, der darauf hinaus läuft, dass es einfach nicht geht. Der ...“
Optionen

Ja, Andreas. Was du schreibst, leuchtet mir ein bzw. habe ich eigentlich auch vorher schon gewusst. Der Verwaltungsaufwand bei 1000 kleinen Dateien ist natürlich 1000 Mal grösser als bei 1 Datei, die eine Grösse der 1000 kleinen hat. Somit wird es immer einen krassen Unterschied geben, egal wie schnell die Festplatten noch werden.

Meine Frage ging aber mehr in die Richtung, warum man eigentlich diesen Verwaltungsaufwand bzw. dessen Bearbeitungsdauer nicht drastisch verschnellern kann. Oder noch anders gefragt: Warum setzt man alle "Energie" in eine grundsätzlich höhere Datenübertragung, wenn doch in der Praxis eher gefragt wäre, diese Verwaltungsgeschwindigkeit zu erhöhen, weil man eher selten wenige riesige Daten liest / schreibt als kleine (z. B. Internet, Booten, Programm-Starts, Foto-Ordner einlesen etc.)?

bei Antwort benachrichtigen
Andreas42 Sovebämse „Ja, Andreas. Was du schreibst, leuchtet mir ein bzw. habe ich eigentlich auch vorher schon gewusst. Der Verwaltungsaufwand ...“
Optionen

Hi!

Da kommt man dann mehr in den Bereich der Software Entwicklung. Dazu muss man sich dann die Frage stellen, braucht man viele kleine Dateien (zur Konfiguration)?
In der Praxis ist mir aufgefallen, dass man dazu immer häufiger auf Datenbanken zurückgreift. Die speichern dann viele kleine Datenmengen in einer größeren Datenbankdatei und umgehen damit dann den Verwaltungsaufwand für einzelne Dateien. Macht durchaus Sinn.

Andererseits sitze ich in der Praxis an einem ERP-Programm, dessen Kerntechnik noch aus den 90er Jahren kommt. Die schreiben Konfigurationsdaten aus der Datenbank in kleine ASCII-Dateien, um sie schneller lesbar zu machen. Örgs!

Und weil das ja so nicht wirklich klappt (siehe Oben), werden diese Laufzeitdaten, dann auf dem ERP-Server im RAM gehalten ("Shared memory" wird das genannt), so dass die ganzen Userprozesse diese Laufzeitdaten direkt vorfinden und nicht erst kompliziert laden müssen. (Zur Entlastung muss man sagen: als das erfunden wurde, hatten die noch keine echte Datenbank unterm Hintern, sondern haben die einzelnen Tabellendaten wirklich als normale Dateien im Filesystem gespeichert.)

Man hat also bereits seit Jahrzehnten Methoden, um mit diesem Klein/Klein umzugehen. Trotzdem bleibt es ein Murks.

Übrigens war der letzte mir bekannte Schrei im Datenbankumfeld, die komplette Datenbank komprimiert im RAM des Datenbank-Servers zu halten. Dann spart man sich die ganzen Leseoperationen auf der Platte. (Link zur Zauberei)

Bis dann
Andreas

Hier steht was ueber mein altes Hard- und Softwaregedoens.
bei Antwort benachrichtigen
Sovebämse Andreas42 „Hi! Da kommt man dann mehr in den Bereich der Software Entwicklung. Dazu muss man sich dann die Frage stellen, braucht man ...“
Optionen

Ja, das ist eine berechtigte Frage bzw. wäre der richtige Ansatz, alles in grosse Dateien zu schreiben. Jedoch: braucht es dann nicht auch einen gewissen Zeitaufwand, um das Gewünschte innerhalb einer riesigen Datei zu finden? Gut, der Vorteil ist, sie kann schnell in den RAM geladen werden, wo dann der Inhalt sehr viel schneller zur Verfügung steht.

Anderes wird man schwer in einzelne grosse Dateien quetschen können wie z. B. Fotos. Wenn ich einen Ordner im Irfanview mit kleinen Bildchen anzeigen will, der ca. 300 Fotos mit je 5 MB umfasst, dauert das doch noch ein paar Sekunden, selbst von einer SSD. Oder der Updateprozess dauert auch noch recht lange (auch da gibt's schon Verbesserungen). Das sind so Vorgänge, die einem das Gefühl von "Langsamkeit" am Computer noch vermitteln.

Aber es ist ja schon so: der Boot- und die Programm-Startprozesse sind heute schon so optimiert und schnell, dass es langsam eher an der Hardware-Initialisierung (langsamer POST des Mainboards oder Zusatzkarten) oder Programmierfehlern / Treiberproblemen / Hängern / Problemen durch Add-Ons etc. hängt, wenn mal etwas langsam läuft. Windows selbst und die meiste Software starten ja heute bereits innert weniger Sekunden oder sogar Bruchteilen davon.

bei Antwort benachrichtigen
Borlander Sovebämse „Ja, das ist eine berechtigte Frage bzw. wäre der richtige Ansatz, alles in grosse Dateien zu schreiben. Jedoch: braucht es ...“
Optionen
Ja, das ist eine berechtigte Frage bzw. wäre der richtige Ansatz, alles in grosse Dateien zu schreiben. Jedoch: braucht es dann nicht auch einen gewissen Zeitaufwand, um das Gewünschte innerhalb einer riesigen Datei zu finden? Gut, der Vorteil ist, sie kann schnell in den RAM geladen werden, wo dann der Inhalt sehr viel schneller zur Verfügung steht.

Dann hast Du statt einer kompletten Partition plötzlich eine große Container-Datei mit einem eigenen Dateisystem: Damit verschiebst Du das vorhandene Problem am Ende nur eine Ebene weiter, löst es aber nicht (zumindest nicht universell).

Wenn ich einen Ordner im Irfanview mit kleinen Bildchen anzeigen will, der ca. 300 Fotos mit je 5 MB umfasst, dauert das doch noch ein paar Sekunden, selbst von einer SSD.

Da spielt aber nicht nur die Lesegeschwindigkeit eine Rolle, sondern es müssen auch noch die Bilddaten dekomprimiert werden bis zur Darstellung.

bei Antwort benachrichtigen
Borlander Sovebämse „Wie schnell ist RAM bei kleinen Dateien?“
Optionen
Zudem die Frage: Wird es in Zukunft mal möglich sein, das Lesen kleiner Dateien fast so schnell hinzukriegen wie das Lesen grosser Dateien?

Ziemlich sicher nicht. Und vor allem nicht in Form eines universellen Dateisystems. Für Anwendungen wie den Start eines Betriebssystems könnte man ggf. durch Einsatz von für diesen Einsatzzweck optimierten Speicherabbildern (die dann als eine große Datei im Dateisystem liegen) ein bisschen mehr Leistung rauskitzeln, wird dafür dann aber vorher wesentlich mehr Zeit zur Optimierung investieren müssen.

Jetzt versuchen wir das ganze noch noch mal etwas zu quantifizieren:

Lesegeschwindigkeit[B/s] := Dateigröße[B] / Gesamtlesedauer[s]

Die gesamte Lesedauer beschränkt sich nun aber nicht nur auf die Inhalte, sondern umfasst auch noch den Zeitbedarf für den Zugriff (was offensichtlich mindestens so lange dauern wird wie das Lesen der entsprechenden Organisationsstrukturen) selbst. D.h.:

Gesamtlesedauer[s] := Zugriffsdauer[s] + Inhaltslesedauer[s].

Die Zugriffsdauer ist fast (bzw. wächst zumindest um Größenordnungen langsamer als die Dateigröße) unabhängig von der Dateigröße. Für große Dateien können wir dann

Zugriffsdauer << Inhaltslesedauer

annehmen (und somit gilt Lesegeschwindigkeit[B/s] ~ Dateigröße[B] / Inhaltslesedauer[s] ), aber für kleine Dateien kann das sogar in Richtung

Zugriffsdauer >> Inhaltslesedauer

gehen und fällt die Lesegeschwindigkeit am Ende eher enttäuschend aus. Wobei bei kleinen Datenmengen u.A. durch das Warten und Caching der Zeitbedarf relativ höher ausfällt.

bei Antwort benachrichtigen