Sinnvolle Größe eines Byteblocks beim Kopieren
-
Hi.
Ich habe ein Programm, welches eine beliebige Binärdatei nimmt und sie in eine andere Datei Byte-für-Byte hineinkopiert. Weil das Programm dabei wirklich Byte-für-Byte kopiert ist das ganze warscheinlich sehr langsam. Wenn ich einen größeren Byte-Block auslese und den dann in die andere Datei schreibe ist das bestimmt sehr viel schneller... Aber welche Größe ist sinnvoll? Woran orientiert man sich dabei?
-
Welche Größe sinnvoll ist? Die der Datei vermutlich.
-
Was ist, wenn die Datei 300 MB groß ist? Dann ist der Arbeitsspeicher direkt voll...
-
Die meisten Dateien sind zwischen 1 KB und 1 MB groß, eventuell etwas dazwischen. Sagen wir 4096 Bytes?
MfG SideWinder
-
4096kb ist am besten für große dateien,weil das der pagesize der festplatte entspricht.
-
otze schrieb:
4096kb ist am besten für große dateien,weil das der pagesize der festplatte entspricht.
Ist die nicht inzwischen bei 8192 angelangt, oder ist das der Cache?
MfG SideWinder
-
Hallo,
verwende doch einfach deine platformspezifische Kopierfunktion.
-
Cold hard Bitch schrieb:
Hi. Ich habe ein Programm, welches eine beliebige Binärdatei nimmt und sie in eine andere Datei Byte-für-Byte hineinkopiert. Weil das Programm dabei wirklich Byte-für-Byte kopiert ist das ganze warscheinlich sehr langsam. Wenn ich einen größeren Byte-Block auslese und den dann in die andere Datei schreibe ist das bestimmt sehr viel schneller... Aber welche Größe ist sinnvoll? Woran orientiert man sich dabei?
messen hilft.
vor langer zeit hab ich mal ausgemessen, und es war so, daß von 1 bis ca 128 die performache rasant anstieg, bis 8192 immer undeutlicher anstieg und drüberhinaus ich keinen ansteig mehr sah.
die pagesize von 4096 zu nehmen ist ein guter tip. naja, nimm gleich 8192, dann brauchste nachher für die 64-bittigen prozessoren die zahl nicht mehr zu ändern.
das kopieren inerhalb der blöcke darf natürlich nicht byte für byte geschehen, sondern minstestens mal int für int. evtl noch ein duff's device dazu, muß man ausmessen.
wenn die plattform die asynchrones lesen/schreiben erlaubt, bringt das gewöhnlich noch was, aber auf kosten von sehr kompliziertem code.
und noch was lächerliches kundzutun: mit einiger mühe kann man die plattformspezifische von win schlagen.
aber alles, nachdem du sowas ab 2048 als blockgröße genommen hast und per memcpy oder intweise kopiertst, ist irelevant wenig steigerung.
-
mit einiger mühe kann man die plattformspezifische von win schlagen.
LOOOOL iich wusste es doch, ms is schlecht^^
-
vor langer zeit hab ich mal ausgemessen, und es war so, daß von 1 bis ca 128 die performache rasant anstieg, bis 8192 immer undeutlicher anstieg und drüberhinaus ich keinen ansteig mehr sah.
Ich kann das bestätigen jedoch versteh ich es nicht wirklich. Ich dachte fstreams wären gebuffert, also wieso können sie nicht automatisch in 4096 Byte blöcken lesen/schreiben