datei-kopieren nach K&R --> performance?
-
hi!
im buch von Kenighan & Ritchie steht ein beispiel, in dem eine datei in eine andere via einer schleife und fgetc/fputc kopiert wird.
dumm nachgedacht hiesse das ja, das der lesekopf der HDD pro byte einmal hin und einmal zurück muss (source -> destination & wieder zurück). kann ich mir aber nicht vorstellen, da das ziemlich lahm und vor allem hardware-strapazierend währe.
haben HDDs so eine art buffer, z.B. dass beim lesen eines bytes provisorisch gleich mal alle folgenden 1023 und alle vorigen 1023 mitgelesen und irgendwie gepuffert werden? oder übernimmt das OS das und schreibt erst z.b. beim schliessen des files?
oder heisst das einfach das ein verantwortungsvoller coder nicht byteweise sondern lieber gleich nen ganzen buffer schreibt?
mfg,
---loki
-
loki1985 schrieb:
im buch von Kenighan & Ritchie steht ein beispiel, in dem eine datei in eine andere via einer schleife und fgetc/fputc kopiert wird.
dumm nachgedacht hiesse das ja, das der lesekopf der HDD pro byte einmal hin und einmal zurück muss
Im K&R steht doch bestimmt auch, dass die stdio-Funktionen gepuffert arbeiten.
haben HDDs so eine art buffer, z.B. dass beim lesen eines bytes provisorisch gleich mal alle folgenden 1023 und alle vorigen 1023 mitgelesen und irgendwie gepuffert werden? oder übernimmt das OS das und schreibt erst z.b. beim schliessen des files?
Es wird auf mehreren Ebenen gepuffert. Zuerstmal sind Platten ja sektorenweise organsisiert, d.h. selbst wenn du nur 1 Byte wolltest würden immer mindestens 512 gelesen. Dann gibts auch noch einen platteninternen Cache.
Das OS selbst puffert auch ziemlich viel, und versucht dabei die Zugriffe optimal auszuführen, d.h. es ordnet die Zugriffe so um, dass es bspw. eine Spur mit einmal schreiben kann o.ä.
Letztendlich besteht dann applikationsseitig nochmal eine Pufferung (wie gesagt, das übernehmen die stdio-Funktionen). Es wär also absoluter Overkill, da noch eine Pufferungsschicht drüberzulegen.
-
ok, danke.
das heisst ich kann beruhigt weiter mit fgetc/fputc arbeiten
-
Bashar schrieb:
Dann gibts auch noch einen platteninternen Cache.
und das macht viel Unterschied. Denn eine gute Cache Strategie kann zu einer guter Laufzeit führen, und ich würde sagen, es gibt keine Festplatte, die kein Cache hat.
-
Bashar schrieb:
Letztendlich besteht dann applikationsseitig nochmal eine Pufferung (wie gesagt, das übernehmen die stdio-Funktionen). Es wär also absoluter Overkill, da noch eine Pufferungsschicht drüberzulegen.
I/O-Aufrufe ans Betriebssystem kosten Zeit; da der Puffer bei der stdio-Library defaultmaessig sehr klein ist (4K-16K), muessen viele I/O-Zugriffe durchgefuehrt werden, um eine Datei zu kopieren.
Mit setvbuf() kann man den Dateipuffer heraufsetzen.
Bei einem Dateikopierprogramm sind mindestens 512K, heutzutage auch 1-4M als Puffergroesse zu empfehlen.
Nachteil der Methode ist, das abwechselnd gelesen und geschrieben wird, mit Pausen, in denen von einem Puffer in den anderen kopiert wird (mittels fgetc() und fputc()).
Wesentlich schneller geht's zunaechst mit fread() / fwrite() (blockweises Lesen/Schreiben) und wenn das nicht reicht, mit direkten Betriebssystemsaufrufen und Overlapped I/O (Windows) bzw. Asynchronous I/O (Linux/UNIX).