FileCopy-Funktion optimieren (Buffer-Size)

[Normalement]

Hallo,

ich nutze folgende Funktion, um Dateien zu kopieren (verkürzte Variante):

Delphi-Quellcode:

function FastFileCopyEx(const InFileName, OutFileName: string): Boolean;
const
 BufSize = 3 * 4 * 4096;
type
 PBuffer = ^TBuffer;
 TBuffer = array [1 .. BufSize] of Byte;
var
  Size: DWord;
  Buffer: PBuffer;
  infile, outfile: file;
begin
 if FileExists(InFileName) then
  begin
   if (InFileName <> OutFileName) then
    begin
     Buffer := nil;
     Assign(infile, InFileName);
     Reset(infile, 1);

     try
      Assign(outfile, OutFileName);
      Rewrite(outfile, 1);
      
      try
       New(Buffer);

       repeat
        BlockRead(infile, Buffer^, BufSize, Size);
        BlockWrite(outfile, Buffer^, Size);
        
        {* ... *}
         
       until Size < BufSize;
      finally
       if Buffer <> nil then
        Dispose(Buffer);

       CloseFile(outfile);
      end;
     finally
      CloseFile(infile);
     end;
    end;
  end;
 {* ... *}
end;

Ist es möglich das Kopieren von Dateien mit einer Änderung der Buffer-Größe zu optimieren?
Warum genau da 3*4*4096 steht, weiß ich nicht mehr, da der Code uralt ist.

[Luckie]

Das hängt von der Größe der zu kopierenden Dateien ab und wie viel Arbeitsspeicher du zur Verfügung hast. Ist der Buffer zu groß muss Windows auslagern. Und das kostet Zeit. Ist der Buffer zu kleine hast du bei großen Dateien viele Lese- und Schreibvorgänge, die auch Zeit kosten. Es wird also immer auf einen Kompromiss hinauslaufen, wenn viele dateien hast die in ihrer Größe sehr unterschiedlich sind.

Merkst du ja auch, wenn du mit Windows viele Dateien kopierst. Da schwankt die Rsetzeitanzeige ja auch immer sehr stark.

[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:

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)

[Normalement]

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:

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

Delphi-Quellcode:

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:

Zitat von Luckie (Beitrag 1333962)

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
:lol:

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/

Anhang 45020 :shock: 2. und vor C++

[Normalement]

Zitat:

Zitat von Luckie (Beitrag 1333962)

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:P 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.