Optimale Buffer größe um große Datenmengen zu speichern

[Jonelmeier]

Hallo!

Also, ich möchte per TFileStream große Mengen an Binärdaten (ca. 300MB) in eine Datei schreiben. Klappt auch alles prima, nur hab ich mich jetzt gefragt, wie groß ich den Buffer machen muss, damit das möglichst schnell geht. Hab schon verschiedene größen ausprobiert, konnte aber nicht wirklich eine Regelmäßigkeit (kleiner Buffer -> Langsam, großer Buffer -> schnell) feststellen.
Vielleicht kann mir ja mal jemand 'nen kleinen Tipp geben, auf was ich achten muss.

Gruß aus Hamburg!
Jonas

[Namenloser]

Kann man pauschal nicht sagen. Das hängt davon ab, wie schnell die Festplatte ist, wie viel RAM verfügbar ist, wie schnell deine Code ist, wie du auf die Daten zugreifst usw. - Da bleibt dir nur übrig, zu experiementieren, jedoch kann es auf jedem System auch wieder anders sein...

[Satty67]

Soweit ich weis, arbeiten FileStreams schon mit Schreib/Lesepuffer. Rein theoretisch solltest Du selbst bei 1 Byte pro Read/Write keinen Unterschied merken, weil der Code normalerweise schneller die Bytes liefert (in den internen Puffer füllt), als die Festplatte arbeitet.

In der Praxis sind aber doch Unterschiede zu merken (wohl wegen der vielen Aufrufe)... Aber ab 1024 Byte hatte ich bei einem kleinen Kopiertool schon keine messbaren Unterschiede mehr bemerkt

[shmia]

Ich habe mal Messungen durchgeführt.
Dabei wird eine Datei mit 2MB mit unterschiedlichen Blockgrössen beschrieben und gelesen.

Zitat:

write 2097152 blocks à 1 bytes: 9893,44 ms
write 1048576 blocks à 2 bytes: 4299,12 ms
write 524288 blocks à 4 bytes: 2123,33 ms
write 262144 blocks à 8 bytes: 1058,08 ms
write 131072 blocks à 16 bytes: 532,53 ms
write 65536 blocks à 32 bytes: 267,13 ms
write 32768 blocks à 64 bytes: 133,15 ms
write 16384 blocks à 128 bytes: 67,83 ms
write 8192 blocks à 256 bytes: 35,17 ms
write 4096 blocks à 512 bytes: 18,39 ms
write 2048 blocks à 1024 bytes: 10,77 ms
write 1024 blocks à 2048 bytes: 7,41 ms
write 512 blocks à 4096 bytes: 5,19 ms
write 256 blocks à 8192 bytes: 4,13 ms
write 128 blocks à 16384 bytes: 3,58 ms
write 64 blocks à 32768 bytes: 3,30 ms
write 32 blocks à 65536 bytes: 3,22 ms
write 16 blocks à 131072 bytes: 3,38 ms
write 8 blocks à 262144 bytes: 4,13 ms

read 2097152 blocks à 1 bytes: 5472,27 ms
read 1048576 blocks à 2 bytes: 2742,54 ms
read 524288 blocks à 4 bytes: 1386,96 ms
read 262144 blocks à 8 bytes: 686,22 ms
read 131072 blocks à 16 bytes: 344,67 ms
read 65536 blocks à 32 bytes: 171,07 ms
read 32768 blocks à 64 bytes: 88,16 ms
read 16384 blocks à 128 bytes: 43,79 ms
read 8192 blocks à 256 bytes: 22,13 ms
read 4096 blocks à 512 bytes: 11,95 ms
read 2048 blocks à 1024 bytes: 6,69 ms
read 1024 blocks à 2048 bytes: 3,85 ms
read 512 blocks à 4096 bytes: 2,51 ms
read 256 blocks à 8192 bytes: 1,90 ms
read 128 blocks à 16384 bytes: 1,51 ms
read 64 blocks à 32768 bytes: 1,36 ms
read 32 blocks à 65536 bytes: 2,97 ms
read 16 blocks à 131072 bytes: 1,93 ms
read 8 blocks à 262144 bytes: 2,88 ms

Ein günstige Puffergrösse wäre wohl 8kB.
Interessant ist, das die Leistung bei Puffer über 32kB eher schlechter wird.

PS: TFileStream ist ungepuffert und sehr nahe am Betriebssystem.

[himitsu]

Zitat von shmia:

PS: TFileStream ist ungepuffert und sehr nahe am Betriebssystem.

abgesehn von der Windows-FileCache (diese ließe sich aber abschalten)

allerdings denken die meißten dann, daß es dann plötzlich langsamer ist, da die "normalen" Meßverfahren nur im Programm ansetzen und dort mit SchreibCache das Schreibbefehl schon zurückkehrt, bevor die Datei wirklich auf der Platte liegt ... macht sich bei sehr großen Dateien schnell bemerkbar ... ist die FileCache voll, reagiert das System schonmal langsamer bis zeitweise garnicht und beim Schließen der Datei dauert es auch länger (halt bis die FileCache fast leer ist).

hatte auch mal einige Testes gemacht (siehe FileSplitter)
und demnach machen sich so 8 bis 64 KB (recht gut) ... ein Optimum gibt es nicht (hängt alles vom jeweiligen Testsystem ab)

ungünstig macht sich vorallem alles, was kein Vielfaches von 512 (Festplatten, Speicherkarten unc Co.) bzw. 4096 (CDs und DVDs) Byte ist ... also sich nicht in ganze Sektoren aufteilen läßt
und optimal ist alles, was mindestens ganzen Sektoren und dazu noch der kleinsten zwischengeschalteten Cache (Festplattecache, FileCache und den ganzen Cachen (L2 und Co.) dazwischen) entspricht.

[Jonelmeier]

Hab mich jetzt für 16kb als Buffer entschieden, das ist bei mir am schnellsten, wobei die Ergebnisse natürlich immer etwas schwanken.
Danke für eure Hilfe!!

Gruß Jonas!

[Dax]

Solche Messunden kann man eigentlich erst dann als sinnvoll betrachten, wenn sie nicht Millisekunden, sondern ganze Sekunden umfassen. Gerade im einstelligen Millisekundenbereich funkt der Scheduler so derartig zwischen den normalen Betrieb eines Programmes, dass es nicht mehr schön ist - mal von den Wartezeiten auf die Platte, die einen Scheduler geradezu zum arbeiten einladen, abgesehen.

[shmia]

Zitat von Dax:

Solche Messunden kann man eigentlich erst dann als sinnvoll betrachten, wenn sie nicht Millisekunden, sondern ganze Sekunden umfassen. Gerade im einstelligen Millisekundenbereich funkt der Scheduler so derartig zwischen den normalen Betrieb eines Programmes, dass es nicht mehr schön ist - mal von den Wartezeiten auf die Platte, die einen Scheduler geradezu zum arbeiten einladen, abgesehen.

Hast ja recht, aber längere Messungen können die Geduld doch sehr strapazieren.

Code:

write 8388608 blocks à 8 bytes: 40176,8 ms
write 4194304 blocks à 16 bytes: 17426,7 ms
write 2097152 blocks à 32 bytes: 8945,0 ms
write 1048576 blocks à 64 bytes: 5454,6 ms
write 524288 blocks à 128 bytes: 5153,7 ms
write 262144 blocks à 256 bytes: 4755,9 ms
write 131072 blocks à 512 bytes: 4623,0 ms
write 65536 blocks à 1024 bytes: 4609,5 ms
write 32768 blocks à 2048 bytes: 4421,9 ms
write 16384 blocks à 4096 bytes: 4477,7 ms
write 8192 blocks à 8192 bytes: 4369,3 ms
write 4096 blocks à 16384 bytes: 4359,5 ms
write 2048 blocks à 32768 bytes: 4377,1 ms
write 1024 blocks à 65536 bytes: 4384,6 ms
write 512 blocks à 131072 bytes: 4365,4 ms
write 256 blocks à 262144 bytes: 4362,1 ms

read 8388608 blocks à 8 bytes: 22099,8 ms
read 4194304 blocks à 16 bytes: 11060,1 ms
read 2097152 blocks à 32 bytes: 5601,4 ms
read 1048576 blocks à 64 bytes: 2841,6 ms
read 524288 blocks à 128 bytes: 1437,6 ms
read 262144 blocks à 256 bytes: 750,3 ms
read 131072 blocks à 512 bytes: 418,3 ms
read 65536 blocks à 1024 bytes: 245,6 ms
read 32768 blocks à 2048 bytes: 160,0 ms
read 16384 blocks à 4096 bytes: 118,1 ms
read 8192 blocks à 8192 bytes: 103,2 ms
read 4096 blocks à 16384 bytes: 82,6 ms
read 2048 blocks à 32768 bytes: 77,4 ms
read 1024 blocks à 65536 bytes: 72,4 ms
read 512 blocks à 131072 bytes: 74,0 ms
read 256 blocks à 262144 bytes: 119,6 ms

[himitsu]

was bei diesen Messungen nicht beachtet wird, ist immernoch die WindowsFileCache ... TFileStream arbeitet per Standard mit dieser Cache.

also kann/wird noch etwas in der Cache sein und muß noch auf die Platte, selbst wenn der Schreibbefehl schon lange beendet wurde.

PS: hatte mal einen PC fast zum erliegen gebracht ... knapp 80 GB über diese Cache, bei nur 1 GB RAM und auf die Systemplatte ... nach wenigen Sekunden fing Windows wegen der Cache an alles auszulagern und ab da war das System teilweise nichtmal mehr bediehnbar.

[shmia]

Zitat von himitsu:

was bei diesen Messungen nicht beachtet wird, ist immernoch die WindowsFileCache ... TFileStream arbeitet per Standard mit dieser Cache.

Ich rufe bei der Messung optional FlushFileBuffers() auf.
Auf meinem Rechner macht das aber wenig Unterschied (zu wenig Cache )
Im Anhang ist das Testprogramm (inkl. Sourcecode).