GetFileSize - welches ist die bessere Funktion?

[Glados]

Ich teste gerade ein paar bei der Suchmaschine meiner Wahl gefundenen GetFileSize-Funktionen aus und vergleiche sie.
Mir ist aufgefallen, dass die FindFirst-Funktion (die erste) langsamer ist als die zweite.

Habt ihr noch bessere / schnellere?

Hier meine Funde

Delphi-Quellcode:

 function GetFileSizeA(const aFileName: string): Int64;
 var
  SR: TSearchRec;
 begin
  Result := 0;

  if not FileExists(aFileName) then
   Exit;

  if FindFirst(aFileName, faAnyFile and not faDirectory, SR) = 0 then
   try
    Result := SR.Size;
   finally
    System.SysUtils.FindClose(SR)
   end;
 end;

 function GetFileSizeB(FileName: string): Int64;
 var
  Handle: Integer;
  iFileSize: Int64;
 begin
  iFileSize := 0;
  Handle := FileOpen(FileName, fmOpenRead);

  if Handle <> -1 then
   try
    iFileSize := iFileSize + FileSeek(Handle, Int64(0), 2);
   finally
    FileClose(Handle);
   end;

  Result := iFileSize;
 end;

 function GetFileSizeC(aFileName: string): Int64;
 var
  F: TSearchRec;
 begin
  if FindFirst(aFileName, faAnyFile, F) = 0 then
   try
    Int64Rec(Result).Hi := F.FindData.nFileSizeHigh;
    Int64Rec(Result).Lo := F.FindData.nFileSizeLow;
   finally
    System.SysUtils.FindClose(F);
   end;
 end;

[Uwe Raabe]

GetFileSizeA macht vorher noch ein überflüssiges FileExists. Ist die immer noch langsamer wenn du das weglässt?

Hast du schon mal GetFileSize aus Winapi.Windows versucht?

[Glados]

Wenn ich bei A das FileExists weglasse, ist es noch langsamer als B.

Wenn die Datei existiert, ist die Reihenfolge von schnell nach langsam: C, B, A

Wenn die Datei nicht existiert: B, C, A (hier ist B etwa doppelt so schnell wie A und B)

[Uwe Raabe]

Wie misst du denn die Zeiten? Vielleicht spielt da der Windows-Filecache eine Rolle?

[Glados]

Das mit dem FileCache ist nicht so wichtig.

Delphi-Quellcode:

var
 SW: TStopwatch;
 i, X: Integer;
 D1, D2, D3: Integer;

const
 FILE_: string = '\\?\D:\2017-06-12 16-54-48.mkv';
begin
 SW := TStopwatch.Create;
 SW.Start;
 for i := 0 to 9999 do
  X := GetFileSizeA(FILE_);
 SW.Stop;
 D1 := SW.ElapsedMilliseconds;

 SW := TStopwatch.Create;
 SW.Start;
 for i := 0 to 9999 do
  X := GetFileSizeB(FILE_);
 SW.Stop;
 D2 := SW.ElapsedMilliseconds;

 SW := TStopwatch.Create;
 SW.Start;
 for i := 0 to 9999 do
  X := GetFileSizeC(FILE_);
 SW.Stop;
 D3 := SW.ElapsedMilliseconds;

 Caption := X.ToString; // nur, damit X nicht wegoptimiert wird
 Caption := D1.ToString + ' - ' + D2.ToString + ' - ' + D3.ToString;

[himitsu]

Zitat:

Das mit dem FileCache ist nicht so wichtig.

Doch?

Wenn der erste aufruf 10 Sekunden dauert und die nachfolgenden 9999 nur 1 Millisekunde,
dann sieht es fast langsamer aus, als die andere Variante, wo alle Aufrufe 2 Millisekunden dauern.
Im realen Betrieb sieht es oftmals auch so aus, dass es den Cache nicht gibt und alles "neu" eingelesen wird.

Außerdem ist dieser Test nicht aussagefähig, denn es ist ein Unterschied, ob man von 10.000 Dateien einmal den Wert ausliest,
oder ob man es "sinnlos" 10.000 Mal bei der selben Datei im selben Verzeichnis macht.
Und noch sinnloser sind solche "Benchmarks", wenn am Ende noch andere Dinge gemacht werden und es da auf das Zusammenspiel drauf ankommt.

Ich kann noch so oft mein Tempo auf 100 Meter messen und das Ergebnis für gut befinden, aber beim Marathon bin ich dennoch voll am Arsch.


Und dann kann der eine Code gern 1% schneller sein, aber sein Code ist grauenhaft ... dann doch lieber der andere etwas Langsamere, der aber wenigstens viel schönder und fehlerunanfälliger ist. (außer es komt einmal, was extrem selten vorkommt, doch auf jede Nanosekunde drauf an)
Zusätzlich kommt es auch noch auf die Hardware drauf an, denn wenn das Programm beim Entwickler schnell ist, aber in den Zielumgebungen sich selber sinnlos ausbemst, dann bringt es garnichts.


Bestes Beispiel sind die schwachsinnigen Dateikopierdialoge vom Windows Explorer ... die könnten und waren früher mal wesentlich schneller, aber jetzt kannst du die Performance komplett vergessen. (beim Kopieren einzelner/weniger Dateien)

[Glados]

Zitat:

Doch?

Mir ist es aber recht egal.

Zitat:

Und noch sinnloser sind solche "Benchmarks", wenn am Ende noch andere Dinge gemacht werden

Wo werden denn andere Dinge gemacht?

Ist jetzt aber gut. Kannst aufhören auf mich einzuschlagen.

[Luckie]

Wenn es dir egal ist, dass der FileCache mit reinspielt und du so keine vergleichbaren Ergebnisse bekommst, dann ist das ganze doch irgendwie sinnlos. :?

[Glados]

Das mit dem Cache ist doch so:
wenn Windows nicht aus dem Cache ließt, dann wird das Ganze sicherlich sehr sehr viel länger dauern. Oder irre ich mich?
Das hier dauert bei mir nur rund 180ms. Ich kann mir nicht vorstellen, dass hier ohne Cache gearbeitet wird.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1383847)

Das mit dem Cache ist doch so:
wenn Windows nicht aus dem Cache ließt, dann wird das Ganze sicherlich sehr sehr viel länger dauern. Oder irre ich mich?
Das hier dauert bei mir nur rund 180ms. Ich kann mir nicht vorstellen, dass hier ohne Cache gearbeitet wird.

Bis auf den ersten Zugriff ist das wohl auch so. Deswegen solltest du einen zusätzlichen Aufruf vor die erste Messung machen, damit der Nicht-Cache-Zugriff diese nicht verfälscht. Du kannst auch mal die Reihenfolge der Aufrufe vertauschen. Z.B. erst C, dann B dann A. Bekommst du dann dasselbe Ergebnis bezüglich der Performance?