FileCopy-Funktion optimieren (Buffer-Size)

**Sir Rufo**

Die 4096 kommen von der Standard-Cluster-Größe bei NTFS Partitionen. Generell sollte man beim Buffer immer ein Vielfaches der Clustergröße verwenden, damit ein Cluster nicht mehrmals gelesen werden muss.

https://support.microsoft.com/de-de/kb/140365

Die maximale Clustergröße ist 128KB darum würde ich die als Minimum schon mal ansetzen (ist ja auch ein Vielfaches von 4096).

Aufpassen muss man jetzt nur bei parallel ablaufenden Kopieroperationen, denn nun könnte der RAM-Speicher auch knapp werden (32bit Anwendungen). Hier ist eine Begrenzung der gleichzeitigen Kopieraktionen sinnvoll - auch im Hinblick auf die Platten selber. Bei SSD-Platten spielen "quasi parallele" Zugriffe kaum eine Geige, bei Magnetplatten kann man dadurch die Kopierleistung erfolgreich senken.

BTW: Die einfachste Kopiermethode für Dateien ist die Verwendung von Streams:

zusammenfalten · markieren

Delphi-Quellcode:

			procedure CopyFile( const ASource, ADest: string );

begin

  dst := nil;

  src := TFileStream.Create( ASource, fmOpen or fmShareDenyWrite );

  try

    dst := TFileStream.Create( ADest, fmCreate or fmShareExclusive );

    dst.CopyFrom( src, 0 );

  finally

    dst.Free;

    src.Free;

  end;

end;

TStream.CopyFrom verwendet einen Buffer von x*4096 (gerade den Source nicht zur Hand)

Danke für eure Antworten!
Leider wäre es jetzt eine Qual, von meiner Funktion in eine Stream-Funktion umzuschreiben.

Eine Idee, welche bisher nur im Kopf existiert wäre ungefähr so:

markieren

Delphi-Quellcode:

			const

 {$IFDEF WIN32}

   BufSize = 4 * 4096;

 {$ELSE}

   BufSize = 8 * 4096;

 {$ENDIF}

Wäre das eine Idee?

Ansonsten würde ich zusätzlich noch alle Dateien zählen und die Durchschnittsgröße berechnen und anhand dessen entschieden.
Schlimmsten Falls könnte ich noch eine Fallunterscheidung machen (<= 4GB RAM etc.)

**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.

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 / Delphi-Referenz durchsuchen

TFile.Copy
MSDN-Library durchsuchen

CopyFile2

CopyFileEx
MSDN-Library durchsuchen

CopyFileTransacted
MSDN-Library durchsuchen

ShFileOperation
...
Hier im Forum suchen

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++

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.

FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

AW: FileCopy-Funktion optimieren (Buffer-Size)

Forumregeln

Luckie Registriert seit: 29. Mai 2002 37.621 Beiträge Delphi 2006 Professional	#6 AW: FileCopy-Funktion optimieren (Buffer-Size) 27. Mär 2016, 23:03 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. Michael Ein Teil meines Codes würde euch verunsichern.
	Zitat