A.K.A. "Ich wollte doch nur Dateien kopieren..."

alzaimar hat mich darauf hingewiesen, daß ein kopieren von dateien mit ReadFileScatter und WriteFileGather um einiges schneller sein könnte als mit anderen methoden. informationen über diese beiden funktionen sind rar gesäht, und ich scheitere an der delphi-implementation.

ReadFileScatter und der zugehörige datentyp FILE_SEGMENT_ELEMENT sind delphi unbekannt. wie ich externe funktionen linke ist mir bekannt, allerdings weiss ich nicht wie ich den datentyp deklarieren muss und wie ich dann damit umgehe.

der übersichtlichkeit halber fange ich dafür ein neues topic an und antworte hier:

alzaimar hat folgendes geschrieben:

Das Lustige am Scatter/Gather-IO ist, das (glaube ich) bis zu 8 (System-)Seiten ECHT parallel eingelesen werden können. Du kannst also eine gewaltige Steigerung des Durchsatzes erwarten. WaitFor ist der Preis für's asynchrone Arbeiten. Wann musst Du denn warten? Wer sagt, das das immer direkt nach dem Aufruf von Write/Read erfolgen muss? Kannst Du nicht andere Dinge in der Zwischenzeit erledigen? Desweiteren könntest Du mit asynchronem Kopieren mittels zweier Thread experimentieren. Das klappt solange sich die Dateien nicht über die gleiche HD gehen...

klingt ja alles nicht schlecht.
in der zwischenzeit habe ich nicht wirklich was zu tun. mein programm kopiert nur. mich hat es nur gewundert, warum das asynchrone lesen mit warten schneller sein soll als synchrones lesen.

zwei threads... uh, gerne, aber nicht für die erste "rohversion". ich will doch "nur kopieren"

FILE_SEGMENT_ELEMENT sind nur spezielle 64-bit pointer. Du bekommst Die einfach, indem Du die 32-bit Adresse einer systempage in die untersten 32 bit des pointers kopierst und die oberen auf 0 setzt. Ich würde das so definieren:

Jetzt musst Du nur noch die Seitengröße per GetSystemInfo ermitteln, und dann alloziieren.

Moderiert von Christian S.: Code- durch Delphi-Tags ersetzt.

ich hatte bisher noch nicht viel zeit mich damit zu beschäftigen und komme auch nicht wirklich ganz zurecht. ist das FILE_SEGMENT wirklich nur ein pointer? in der MSDN steht folgendes:

Zitat:

typedef union _FILE_SEGMENT_ELEMENT { PVOID64 Buffer; ULONGLONG Alignment; }FILE_SEGMENT_ELEMENT, *PFILE_SEGMENT_ELEMENT;

was hat das "Alignment" zu bedeuten?
der beispielcode in C verwendet ganz normal VirtualAlloc zum alloziieren, was hat das dann mit systempages zu tun? nur die größe ist relevant?

ein weiteres problem sehe ich hier:

Zitat:

SYMPTOMS Attempting to use a READFILESCATTER operation to read data from a CD-ROM does not work, generating the following error message: The parameter is incorrect CAUSE The READFILESCATTER operation is not supported by the CDFS file system

support.microsoft.co...scid=kb;EN-US;244145

dort wird auch ein patch angesprochen, aber er ist nicht direkt zum download verfügbar. außerdem möchte ich daß mein programm ohne komplikationen auf allen systemen ab 2000 und wenn möglich NT funktioniert. so wie ich den artikel verstehe betrifft das nur windows NT, das könnte man vorerst vernachlässigen - muss aber getestet werden. natürlich wäre denkbar, für CDFS eine andere methode zu verwenden - vorher möchte ich aber gerne sehen, ob es wirklich geschwindigkeitsunterschiede bringt. hat denn noch niemand diese methode implementiert wenn sie doch so toll ist??

Im SQL-Server ist sie implementiert. Deshalb wurde sie auch in NT eingeführt. Der Einsatz der Routinen brachte SQL-Server einen beträchtlichen Vorteil gegenüber der Konkurrenz. Es ist also verdammt schnell. Leider sind meine Versuche damit schon 3 oder 4 Jahre her. Die Systempages müssen genau der Größe entsprechen. Irgendwelche Flags musst du angeben, damit das eben 'Systemseiten' werden.

Zu den File_Segment Dingern fällt mir jetzt nichts mehr ein. Ich war mir sicher, das so gehandhabt zu haben, aber so genau weiss ich das nicht mehr.

Leider ist der Code auch futsch