GetFileSize - welches ist die bessere Funktion?

[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 von 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.

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?

[Jasocul]

Zitat von Glados:

Das hier dauert bei mir nur rund 180ms.

Dann sind deine Prüfschleifen zu kurz.
Um Einflüsse durch das Betriebssystem zu minimieren, muss es ausreichend lange laufen.
Der Cache wurde als Problem schon genannt.
Aber auch jeder Task, Dienst, etc. nimmt Einfluss. Spätestens, wenn irgendein anderer Thread etwas mit der Festplatte macht, werden die Messungen nahezu sinnlos, wenn nur so kurze Zeiträume verwendet werden.
Ich nehme außerdem mal an, dass du keinen speziellen Rechner für die Tests verwendest. Das heißt, dass jeder neue Durchlauf andere Bedingungen hat. Wenn du zum Beispiel deine Test-Anwendung neu kompiliert hast, sind die Voraussetzungen verändert.

Wenn du also ernsthaft feststellen willst, welches die schnellste Variante ist, musst du erstmal die Testumgebung optimieren. Ansonsten sind deine Ergebnisse nicht wirklich aussagekräftig.

btw: Ich habe selbst eine kleine Anwendungen, die Dateien im mittleren 6-stelligen Bereich verarbeitet. Das Einlesen der Informationen dauert i.d.R. weniger als 3 Minuten, wobei die Visualisierung und Sortierung schon enthalten sind. Über eine großartige Optimierung habe ich mir nur wenige Gedanken gemacht, da es meistens ein automatisierter Prozess ist.
Daher stellt sich mir die Frage, wofür brauchst du denn eine derartige Optimierung?