Heiko hat folgendes geschrieben:

jaenicke hat folgendes geschrieben: Dein Programm braucht für die Suche in C:\Programme nach *.txt 89 Sekunden und findet 1212 Dateien, die Windows-Suche blockiert während der Suche nicht, zeigt sofort an wo es ist und was es bisher gefunden hat und braucht 32 Sekunden... Aha - war ein rechnerneustart dazwischen oder ein paar Stunden? Bestimmt nicht. Dann drehe mal den Spieß um. in dem Ordner erst mit der WinSuche suchen und dann mit dem Proggi. Was stellste fest? Genau, die WinSuche ist diesmal langsamer.- Ursache: Windows cacht seine Ergebnisse, von daher schwer vergleichbar - außer du startest die Zeitmessung erst nach einer Suche - denn dann kannste die Verarbeitungsgeschwindigkeit vergleichen, was nen bissl unabhängiger von der Platte sein sollte als die erste Suche.

Es handelt sich (wie bei fast allen Softwaretests, die ich durchführe) um eine virtuelle Maschine. Diese wird vor jedem Test auf den Originalzustand zurückgesetzt und dann erneut gestartet.

// EDIT: Selbst wenn ich die Windows-Suche ca. 50 Sekunden später starte wird sie noch früher fertig als das hier vorgestellte Programm.

// EDIT2: Die Dateianzahl muss ich erneut überprüfen, in der virtuellen Maschine war die XP-interne Unterstützung für ZIP-Archive tatsächlich noch eingeschaltet.

jaenicke hat folgendes geschrieben:

// EDIT: Selbst wenn ich die Windows-Suche ca. 50 Sekunden später starte wird sie noch früher fertig als das hier vorgestellte Programm.

Vergleiche die WinSuche mal bitte mit der Demo hier. Theoretisch dürfte kein Unterschied bestehen. Die Demo dürfte also fdas Maximum darstellen, was man mit Delphi herausholen kann - und diese Unit kann klugmann auch bei sich einbauen, denn dann ist das Problem mit dem ProcessMessages weg

Habe ich gemacht, aber die Ergebnisse sind komisch. Die Windows-Suche brauchte für die Festplatte (bei einem realen PC diesmal) 5,5 Sekunden, dein Tool 3,5 Sekunden, auch bei Wiederholungen sind die Abweichungen davon minimal.

Das Tool aus dem Thread hier war beim ersten Mal mit 19,5 Sekunden sehr viel langsamer, dann mit 4 Sekunden sehr schnell, dann wieder bei 12,5 Sekunden, 6,5 Sekunden... Ich kann mir das nicht erklären. Der Zustand des PCs ist bei jedem Teststart zurückgesetzt. Allerdings ist die Festplatte des PCs auch zu klein um mit vielen Dateien verlässliche Ergebnisse zu liefern.

Auf dem ursprünglich getesteten System war die Suche bei einem weiteren Test im Rahmen (ca. 5 Sekunden Unterschied zur Windows-Suche), auch bei mehreren Tests.

Wir schweifen aber langsam etwas ab glaube ich, es geht ja nicht nur um die Performance.

Naja.Es ist ja so das mein tool alle gefundenen
dateien in ein Stringlist schreibt.Und es dauert eben lange wenn
man dann ne ganze stringlist übertragen muss (auf die Listbox).Die Suche selber ist nicht das Problem.

Es dauert jetzt noch ein bisschen bis zur nächsten Version.Rechnet mit ihr Mittwoch.
hab ja viel zu verbessern:
-Indexierungsdienst
-Thread
-Ausgabe des Suchergebnisses
-weitere Features

Hallo,

wenn du mit Stringlisten arbeitest ist es ja kein wunder. Nimm VirtualStringTree. Das ist 1000x schneller

Grüße
Heiko

Ups ich arbeite mit einem Array.Ich werds mal ausprobieren-

Array kommt auf ziemlich das gleiche. Das Problem ist, dass Setlength dauernd aufgerufen wird. Wie oft rufste es auf? Bei jedem neuem Element? Das ist extrem lahmarschig. Wenn dann schon in größeren Schritten. Trotzdem wird VSt schneller sein, denn das basiert auf Zeigern. Der Overhead für die Zeiger lohnt sich imho - braucht aber auch nen bissl Erfahrung

Ach das bekomm ich hin.

Ach ja, und es heißt Indizierungsdienst. Nicht, dass du dich wunderst, wenn eine Google-Suche nichts ergibt oder so...