ReadFile und WriteFile durch Threads optmieren

[LTE5]

Ich benutze schon immer ReadFile und WriteFile, um eine Datei zu kopieren.
So kopiere ich 2 10 GB Dateien von einer SSD innerhalb von 4 Minuten und 25 Sekunden. Unstoppable Copier braucht dafür 4 Minuten und 10 Sekunden.
Das sind Durchschnittswerte nachdem ich etliche Tests durchlaufen habe. Der Windows-File-Cache war natürlich weg!

Ist es möglich eine Kopierfunktion mit ReadFile und WriteFile so zu trennen, dass ReadFile und WriteFile je in einem Thread laufen?
ReadFile befüllt eine Art Liste von der ich noch absolut keine Ahnung habe wie das sein soll, aus der sich WriteFile dann bedient.

Oder ist ganz davon abzuraten?

[dummzeuch]

Theoretisch kann ReadFile Daten in einen Buffer lesen, aus dem WriteFile dann schreibt. Sowas wie eine Queue von x*4096 Bytes großen Buffern würde sich anbieten.

Aber ob das wirklich schneller ist, kann ich nicht sagen.

[Zacherl]

Zitat:

Zitat von LTE5 (Beitrag 1389681)

Ich benutze schon immer ReadFile und WriteFile, um eine Datei zu kopieren.

Warum verwendest du nicht einfach die entsprechende WindowsAPI anstelle dir mit ReadFile/WriteFile manuell einen abzubrechen? Dort wären solche Optimierungen im Zweifelsfalle nämlich auch schon von Haus aus vorhanden.

[LTE5]

Weil so kann ich
auf Abbrechen reagieren
habe immer die bereits kopierten Bytes und die Bytes die im letzten Durchgang kopiert wurden in Variablen
und ich kann meinen eigenen Buffer setzen

Wie würde man denn das hier mit der WindowsAPI umschreiben? http://www.delphipraxis.net/192758-f...im-thread.html

[Uwe Raabe]

Zitat:

Zitat von Zacherl (Beitrag 1389684)

Warum verwendest du nicht einfach die entsprechende WindowsAPI anstelle dir mit ReadFile/WriteFile manuell einen abzubrechen? Dort wären solche Optimierungen im Zweifelsfalle nämlich auch schon von Haus aus vorhanden.

Ich weiß zwar nicht, ob das noch relevant ist, aber da ist eventuell Vorsicht geboten: Copying large files on Windows

[LTE5]

Verstehe ich das richtig, dass, angenommen der Fall Program X wird von Windows XP bis 10 verwendet, ReadFile und WriteFile vor CopyFile(Ex) vorzuziehen ist, um maximale Kompatibilität zu wahren?

[Uwe Raabe]

Zitat:

Zitat von LTE5 (Beitrag 1389685)

Weil so kann ich
auf Abbrechen reagieren

Die entsprechende Windows-API wäre dann wohl CopyFileEx. Mit den geeigneten Parametern kannst du das jederzeit abbrechen und auch das Buffering abschalten.

[Uwe Raabe]

Zitat:

Zitat von LTE5 (Beitrag 1389687)

Verstehe ich das richtig, dass, angenommen der Fall Program X wird von Windows XP bis 10 verwendet, ReadFile und WriteFile vor CopyFile(Ex) vorzuziehen ist, um maximale Kompatibilität zu wahren?

Gehört XP denn überhaupt zu den unterstützen Zielplattformen von Delphi 10.2 Tokyo? Ich glaube kaum: Unterstützte Zielplattformen

[LTE5]

Mein Programm funktioniert noch wunderbar mit Windows XP.
Man muss nur aufpassen welche Winapi-Aufrufe man macht.

[p80286]

Zitat:

Zitat von LTE5 (Beitrag 1389681)

Ist es möglich eine Kopierfunktion mit ReadFile und WriteFile so zu trennen, dass ReadFile und WriteFile je in einem Thread laufen?
ReadFile befüllt eine Art Liste von der ich noch absolut keine Ahnung habe wie das sein soll, aus der sich WriteFile dann bedient.

Oder ist ganz davon abzuraten?

Es kommt darauf an.
Falls Du die Aktion auf einem einzigen Datenträger ausführen willst könnte das kontraproduktiv sein, es kommt auf die Position(ierung) des Schreiblesekopfes/die Laufwerkselektronik an.
Gleiches gilt im übertragenen Sinne für SSD/USB-Sticks wobei die natürlich keinen Schreib-LeseKopf haben. Im günstigsten Falle, kannst Du den Vorgang um eine Buffergröße verschränken, so daß das Schreiben kurz nach dem Lesen erledigt ist. Ist das Zielmedium beim Schreiben schneller als das Quellmedium beim Lesen, mußt Du für das Schreiben auf jeden Fall ein paar Ehrenrunden mit einrechnen.

Wenn du keine Spezialanwendung hast, bei der Du richtig hardwarenah arbeiten mußt/kannst, halte ich die Idee für verschwendete Zeit. Die paar Zehntel, die Du heraus quetschen kannst, erfordern einen solchen Aufwand daß das nur als Hobby-Anwendung vertretbar ist.
Unterschätze den Test-Aufwand nicht!

Gruß
K-H