FileCopy-Funktion optimieren (Buffer-Size)

[Sir Rufo]

Im Prinzip musst du nur deinen Code durch meinen ersetzen (ein paar Zeilen kannst du von dir behalten) und fertig. Was ist daran schwierig oder eine Qual?

Wenn du die Buffer-Größe selber verwalten möchtest, kopierst du dir den Code von TStream.CopyFrom und änderst die Buffer-Größe.

Eine Abhängigkeit vom der Bittigkeit des Betriebssystems macht keinen Sinn, denn die Clustergröße ist davon nicht abhängig.

Wenn du parallel Dateien kopieren willst (Stichwort Threads) dann solltest du dir einen Datei-Kopier-Service schreiben der die Regie übernimmt. Dort wird dann in Abhängigkeit von der Bittigkeit des Betriebssystems und der Art der Festplatte und den jeweiligen Zielen (physikalische Platten) mehr oder weniger gleichzeitig die Vorgänge abgearbeitet.

[Normalement]

Meine Funktion oben ist sehr beschnitten. Diese benutze ich bereits in Threads mit Callbacks und vielem mehr.
Funktioniert auch richtig gut. Ich dachte nur, man könnte es optimieren ohne alles neu schreiben zu müssen.

Hier gibt es zwar ein gutes Beispiel, wie man einen Callback mit TStream umsetzt, aber ich warte erst einmal damit, da ich doch sehr viel umändern müsste:
http://stackoverflow.com/questions/6...ess-copyfileex

[himitsu]

Fast...

Da DU nur in den WindowsFileCache schreibst, spielt hier auch noch der WindowsFileCache eine Rolle.

Wenn die Dateien (Beide, also Ziel und Quelle) in den RAM passen, dann geht es schnell, aber ist noch lange nicht "geschrieben", was du dann merkst, wenn du große und/oder viele Dateien kopierst.


Ganz im Ernst, lass es und überlass Windows das Kopieren,
die haben sogar eine/mehrere API dafür, man mag es kaum glauben.

[Luckie]

Ergo nutz die API von Windows. Aaaaah. Ich merke gerade, dass ich sehr raus bin aus der Programnmierung. Es gibt eine API, die dir sogar den Fortschrittsdialog abnimmt.

[himitsu]

Zitat von Luckie:

Ergo nutz die API von Windows. Aaaaah. Ich merke gerade, dass ich sehr raus bin aus der Programnmierung. Es gibt eine API, die dir sogar den Fortschrittsdialog abnimmt.

Jupp, Eine, die den Standard-Explorer-Dialog anzeigt,
und eine Andere mit einem Callback.

http://windows.microsoft.com/de-de/w...d-paste-a-file


CopyFile / TFile.Copy
CopyFile2
CopyFileEx
CopyFileTransacted
ShFileOperation
...
Datei kopieren
http://www.delphipraxis.net/1260-dat...operation.html
http://www.delphipraxis.net/43055-wr...operation.html
http://www.delphi-treff.de/tipps-tri...eien-kopieren/

Unbenannt.png 2. und vor C++

[Normalement]

Zitat von Luckie:

Ergo nutz die API von Windows. Aaaaah. Ich merke gerade, dass ich sehr raus bin aus der Programnmierung. Es gibt eine API, die dir sogar den Fortschrittsdialog abnimmt.

Das weiß ich natürlich Aber ich brauchte für ein Projekt einen eigenen Fortschrittsdialog. Sagen wir mal, einen etwas sprachfreudigeren und das überall gleich egal ob Windows 7, 8 oder 10 =)

Er funktioniert vollkommen einwandfrei und es gibt absolut keine Probleme. Ich dachte nur ich frage hier mal nach, ob man am Buffer schrauben könnte.
Frage hat sich aber schon seit den ersten beiden Beiträgen (Luckie und Sir Rufo) erledigt.

[Neutral General]

Zitat von Normalement:

Aber ich brauchte für ein Projekt einen eigenen Fortschrittsdialog. Sagen wir mal, einen etwas sprachfreudigeren und das überall gleich egal ob Windows 7, 8 oder 10 =)

Das kannst du mit CopyFileEx auch haben.
Wenn du trotzdem deinen Uraltcode weiterbenutzen willst probier halt bisschen am Buffer rum und guck was dabei raus kommt.

[himitsu]

Jupp, FileCopyEx + Callback

Aber Achtung: Nicht nicht bei jedem Aufruf die GUI aktualisieren, da du so alles nur ausbremst (Windows ruft den Callback eventuell sehr schnell/oft auf), mit der langsamen GUI.
z.B. per GetTickCount nur, wenn mindestens 200-1000 Millisekunden vergangen sind, seit dem letzten Aktualisieren der GUI.

Und statische Bytegrößen zwischen dem Aktualisieren sind/waren eh schon immer quatsch, da sich das je System/Quelle/Ziel/RAM/Cache anders verhält.