GetFileSize - welches ist die bessere Funktion?

[jbg]

Ich werfe auch noch eine weitere Funktion in den Raum.

Delphi-Quellcode:

function GetFileSizeD(const FileName: string): Int64;
var
  FileInfo: TWin32FileAttributeData;
begin
  FillChar(FileInfo, SizeOf(FileInfo), 0);
  if GetFileAttributesEx(PChar(FileName), GetFileExInfoStandard, @FileInfo) then
  begin
    Int64Rec(Result).Hi := FileInfo.nFileSizeHigh;
    Int64Rec(Result).Lo := FileInfo.nFileSizeLow;
  end
  else
    Result := 0; // -1 wäre ein besserer Wert, da es Dateien gibt die Größe 0 haben
end;

[Glados]

Deine Funktion ist bisher mit Abstand die schnellste.
Sie ist circa fünfmal so schnell wie B.
Ist FindFirst denn wirklich SO langsam und GetFileAttributes(Ex) so viel schneller? Kommt mir schon fast komisch vor.

[jbg]

Zitat von Glados:

Ist FindFirst denn wirklich SO langsam

FindFirstFile, das hinter FindFirst steckt, ist für das Abfragen der Informationen von mehreren Dateien ausgelegt. Wenn du nur eine Datei haben willst, dann ist der Overhead im Vergleich zum GetFileAttributes um einiges größer. Zudem steckt ein anderer System-Aufruf dahinter. Vor allem wenn man auf ein Netzlaufwerk zugreift, wird FindFirstFile so richtig langsam.

Zu FileOpen+FileClose: Virenscanner klinken sich hier sehr gerne ein, und können das ganze gravierend verlangsamen, vor allem beim Öffnen zum Schreiben wird FileClose sehr langsam. Aber auch beim Öffnen zum Lesen prüft der Virenscanner im FileOpen die Datei.

[Glados]

Zitat:

Vor allem wenn man auf ein Netzlaufwerk zugreift, wird FindFirstFile so richtig langsam.

Ja das habe ich schon oft bemerkt. Ich versuche mich da heute mal reinzufuchsen und spiele ein bisschen mit GetFileAttributes rum.
Vielleicht bekomm,t man damit ja sogar ein DirectoryExists hin.

[jbg]

Zitat von Glados:

Vielleicht bekomm,t man damit ja sogar ein DirectoryExists hin.

Ja bekommt man. Im Flags Feld ist dann FILE_ATTRIBUTE_DIRECTORY gesetzt, vorausgesetzt es existiert. Man darf sich vom "File" in GetFileAttribute(Ex) nicht verwirren lassen.

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

[Glados]

Zitat:

Wenn du also ernsthaft feststellen willst, welches die schnellste Variante ist, musst du erstmal die Testumgebung optimieren

Ich behaupte einfach mal, dass das Umsetzen einer speziellen Testumgebung nicht notwendig ist, wenn ein dauerhafter Unterschied von >50% zu sehen ist.

[Codehunter]

Aus der Praxis heraus würde ich sagen, es ist vom Aufwand her um Längen billiger, die Liste der Systemanforderungen um den Punkt SSD (ggf. sogar PCIe-SSD, M.2 usw.) zu ergänzen, als sich derart in Millisekunden zu versteigen. Allerdings gebe ich zu, es gibt Anwendungsfälle wo das absolut gerechtfertigt ist.

Zitat von himitsu:

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)

Boah da hab ich mich letztens auch drüber aufgeregt. Ich kopiere eine Programmverknüpfung im Classic-Shell-Startmenü. Also technisch gesehen eine .LNK, innen drin eine INI und insgesamt eine Handvoll Bytes. Da macht das grottige Windows 10 doch tatsächlich dieses Fenster auf und misst die Kopiergeschwindigkeit nebst Diagrammdarstellung. Allein die Berechnung dessen hat mehr Zeit gefressen als die reine Dateischubserei.

[Jasocul]

Zitat von Glados:

Zitat:

Wenn du also ernsthaft feststellen willst, welches die schnellste Variante ist, musst du erstmal die Testumgebung optimieren

Ich behaupte einfach mal, dass das Umsetzen einer speziellen Testumgebung nicht notwendig ist, wenn ein dauerhafter Unterschied von >50% zu sehen ist.

Behaupten kann man viel.
Dann baue deinen Test doch mal so um, dass er statt 180 ms besser ca. 2 Minuten dauert. Das würde zumindest den Cache-Anteil bei der Bewertung stark verringern. Bleibt der Unterschied dann immer noch bei über 50%, würde ich auch von einer Signifikanz ausgehen.

[Glados]

Zitat:

Dann baue deinen Test doch mal so um, dass er statt 180 ms besser ca. 2 Minuten dauert.

Ich habe zwar keinen gebaut der 2 Minuten dauert, dafür aber mehr als ein paar Millisekunden.

GetFileSizeA: 26 Sekunden Laufzeit
GetFileSizeD: 2 Sekunden Laufzeit