Zitat von
Apollonius:
Alles in allem denke ich, dass es Windows bei Standard-IO so gut macht, wie es geht - also keine zusätzliche Pufferung einführen.
Das wäre natürlich ein Argument, von TFileStream abzuweichen und direkt auf das Windows-
API aufzusetzen. Ehrlich gesagt, war ich bisher einfach zu faul, mich diesbezüglich in die
msdn einzulesen.
Zitat von
himitsu:
Mit den Flags FILE_FLAG_SEQUENTIAL_SCAN und FILE_FLAG_RANDOM_ACCESS (siehe CreateFile ) kann man Windows auch noch mitteilen, in welcher Art man auf die Datei zugreifen will, damit Windows sein Lese-/Speicher-/Cacheverhalten entsprechend optimaler einstellen kann.
Das klingt natürlich sehr interessant!
Zitat von
himitsu:
in welcher Größenordnung liegt denn bei dir der Puffer (die Portionen)?
Von den Algorithmen her möchte ich einfach sequenziell "file of single, file of byte, file of smallint" lesen beziehungsweise schreiben.
Zum Filezugriff verwende ich momentan TFileStream auf einen Lesebuffer von 512kB und
einen Schreibbuffer von 64kB, aus denen ich die singles/bytes/smallints
sequenziell heraushole/hineinschreibe. Zu Beginn dieses Threads hab' ich noch kleinere Buffer (32kB) benutzt, hatte anstatt TFileStream: BlockWrite AssignFile und Co. in Verwendung, und hatte ausserdem noch laufend unnötige Aufrufe von SetFileAttributes und ForceDirectories. Es wird' schon besser
Zitat von
himitsu:
muß unbedingt die ganze Zeit auf der Platte rumgekramt werden,
oder könnte man Teile komplett im
RAM abarbeiten lassen?
Die Daten haben z.B. eine insgesamte Größe von etwa 50GB, momentan seh' ich da nicht viel Chancen, denn sie werden in mehreren "passes" analysiert, d.h. die 50GB werden nach einem Berechnungsschritt wieder komplett für den nächsten Schritt benötigt.
Teilweise sind es sehr lange File (stundenlange Audioaufnahmen, die abgespeichert oder aber analysiert werden wollen), teilweise auch viele kleine Files (etwa 40kB)...
Viele Grüße,
Helmut