GetFileSize - welches ist die bessere Funktion?

[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

[Jasocul]

Das bestätigt dann ja deine Annahme.
OK, war eigentlich abzusehen, da ja FileExists, FindFirst und FindClose in der D-Variante gar nicht vorkommen. Aber dieser Performance-Test war ja noch einfach. Bei komplizierteren Sachen, die nicht so offensichtlich sind, muss man schon genauer testen. Und darum ging es mir an dieser Stelle.

[Uwe Raabe]

Zitat von Jasocul:

Bei komplizierteren Sachen, die nicht so offensichtlich sind, muss man schon genauer testen. Und darum ging es mir an dieser Stelle.

Um strukturelle Fehler im Testaufbau zu finden, sollte man die verschiedenen Durchläufe zunächst immer mit derselben Implementierung laufen lassen (hier alle Messungen erst mit A, dann B usw.). Wenn dann immer die erste Messung signifikant schlechter ist als die folgenden (z.B. wegen des Cache), sollte man den Test solange verbessern bis das ausgeglichen ist.

Das ist so in etwa das Pendant zum Test-Driven Development, bei dem man einen Test bewusst fehlschlagen lässt, um erstmal den Test-Harness zu überprüfen.

[Glados]

Alles erledigt was ihr vorgeschlagen habt.

Resultat:
A = 2 Minuten, 45 Sekunden
D = 31 Sekunden