Luckie's DriveTools in einen Thread auslagern

[Guido Eisenbeis]

Ich weiß, dieser Beitrag ist schon fuuurchtbaar lange her (übermorgen kann man sagen: Von letztem Jahr!) :mrgreen:
Aber ich bin an dem Thema wirklich interessiert. Deshalb hier zwei Fragen:

1. @Daniel G: Würdest du bitte die Früchte deiner Arbeit mit uns teilen? Also einen funktionierenden Code posten oder ein Demo als Anhang?

2. Ist in dem Demo von Lucky aus dem Jahre 2005 nicht auch schon eine Auslagerung in einen eigenen Thread aufgezeigt?

Guido.

[Mithrandir]

Zitat:

Zitat von Guido Eisenbeis

Ich weiß, dieser Beitrag ist schon fuuurchtbaar lange her (übermorgen kann man sagen: Von letztem Jahr!) :mrgreen:

Nee, übermorgen ist er quasi ein Vierteljahr alt. :mrgreen:

Zitat:

Zitat von Guido Eisenbeis

@Daniel G: Würdest du bitte die Früchte deiner Arbeit teilen? Also einen funktionierenden Code posten oder ein Demo als Anhang

Ich musste erst überlegen, was ich damals wollte. Aber jetzt weiß ich es wieder: Das Resultat ist in SmallTune eingeflossen. SmallTune ist OpenSource, die Datei, die du suchst, heißt dgstFindFiles.pas. Ich hab sie mal hochgeladen. ;)

Der Code steht unter der MPL 1.1

[Guido Eisenbeis]

Hallo Daniel G,

zunächst mal danke für die schnelle Antwort und das Hochladen der Datei! :-D

Meine Antwort hat etwas länger gedauert, da ich mich mit deinem Code und dem SmallTune-Projekt beschäftigt habe.

Ich habe den Code in dgstFindFiles.pas schonmal überflogen. Dabei ist mir aufgefallen, dass du eine interessante Art der Implementation der Suchroutinen geschrieben hast! Ich kenne den Ablauf, in dem in einer Schleife nach Ordnern und Unter-Ordnern, und dann rekursiv in einer zweiten Schleife nach Dateien gesucht wird, usw. In deinem Code wird das scheinbar "in einem Aufwisch" gemacht, wobei dann die Filterung per Maske auch auf eine eigene Art erledigt wird.

Wie gesagt, hab den Code erst überflogen. Werd in mir noch näher anschauen!

Ansonsten fehlten da ein paar units, die für diese hier benötigt werden. An der Stelle meinen Dank für den Hinweis mit SmallTune. Da OpenSource hab ich mir die Sourcen gleich runtergeladen und werde mich da auch mal mit schlau machen. :thumb:

Hast du vielleicht ein Aufruf-Beispiel oder ein kleines Demo, bei dem auch das OnProgress gezeigt wird? Würde mich sehr freuen! Denn ich tue mir im Moment ein wenig schwer damit, was wo in welchem Thread abgerufen wird, bzw. ankommt.

Hast du (oder jemand anderes) schon den Code vom Demo von Lucky angesehen? Gibt es da Ähnlichkeiten (Thread auslagern) oder Unterschiede in Bezug auf die Effektivität? Denn der von Lucky scheint mir wirklich flott zu sein!

Guido.

[himitsu]

Zitat:

Zitat von Guido Eisenbeis

Hast du (oder jemand anderes) schon den Code vom Demo von Lucky angesehen? Gibt es da Ähnlichkeiten (Thread auslagern) oder Unterschiede in Bezug auf die Effektivität? Denn der von Lucky scheint mir wirklich flott zu sein!

Flott? (hab das grad mal auf meine Datenplatte losgelassen)

Dort wird doppelt gesucht
- einmal zur initialisierung, worüber das Ende der ProgressBar bestimmt wird
- und dann NOCHMAL für's Suchen

außerdem wird jede Datei in diesem Label angezeigt, was enorm ausbremst

Gerade daß man doppelt suchen muß, ist bei dieser Art des Fortschritts ein Problem.

http://www.delphipraxis.net/internal...t=findallfiles
Dort kann man sich über den Callback anzeigen lassen, wo die Suche sich gerade befindet,
worüber sich dann der User in etwa ausdenken kann, wie lange es eventuell noch dauert
(darüber muß man sich zwar in etwa über seine Ordnerstrucktur im klaren sein, aber wer weiß denn nicht, was er auf seinem Rechner hat :angel2: )

Und sundance bastelt da auch gerade etwas
http://www.delphipraxis.net/internal...t=findallfiles

[Mithrandir]

Zitat:

Zitat von Guido Eisenbeis

Hast du vielleicht ein Aufruf-Beispiel oder ein kleines Demo, bei dem auch das OnProgress gezeigt wird? Würde mich sehr freuen! Denn ich tue mir im Moment ein wenig schwer damit, was wo in welchem Thread abgerufen wird, bzw. ankommt.

Der Code basiert im Endeffekt auf dem CodeLib-Eintrag von SirThornberry. Ich habe lediglich ein paar Definitionen umgeschmissen, um auf die "großen" Units verzichten zu können, da es sich bei SmallTune um ein reines Win32API-Projekt handelt, ohne VCL.
Eigentlich brauchst du als externe Abhängigkeit nur die Like-Funktion.

Der relevante Teil, der den Code nutzt, findet sich hier:

Delphi-Quellcode:

procedure TMediaClass.AddFolderToDatabase(FolderPath: String);
var
  Msk: TMaskArray;
begin
  SetLength(Msk, 4);
  Msk[0] := '*.mp3';
  Msk[1] := '*.ogg';
  Msk[2] := '*.wma';
  Msk[3] := '*.flac';
  FF := TdgstFindFiles.Create(FolderPath, msk, true);
  FF.OnFilesDone := FindFilesDone;
  FF.OnProgress := FindfilesProgress;
  FF.StartSearch;
end;

Wobei TMaskArray einfach ein "Array of String" ist.

OnFilesDone wird aufgerufen, wenn alle Dateien aufgelistet wurden, OnProgress bei jedem Dateifund.

[Luckie]

Zitat:

Zitat von himitsu

Zitat:

Zitat von Guido Eisenbeis

Hast du (oder jemand anderes) schon den Code vom Demo von Lucky angesehen? Gibt es da Ähnlichkeiten (Thread auslagern) oder Unterschiede in Bezug auf die Effektivität? Denn der von Lucky scheint mir wirklich flott zu sein!

Flott? (hab das grad mal auf meine Datenplatte losgelassen)

Dort wird doppelt gesucht
- einmal zur initialisierung, worüber das Ende der ProgressBar bestimmt wird
- und dann NOCHMAL für's Suchen

Aber so weit ich mich erinnere, ist das optional. Man kann das also auch weglassen. Und statt einer Callback arbeite ich eben mit Nachrichten.

[himitsu]

Zitat:

Zitat von Luckie

Aber so weit ich mich erinnere, ist das optional.

Nja, hatte ich bei 'nem eigenem Projekt auch mal so gemacht, weil ich dachte das wäre besser/schöner.
Sobald ich mal Zeit habe dieses zu ändern, wird es bei mir wieder ausgebaut, da es einfach nur nervt, wenn knapp 1,5 Minuten lang eine Initialisierung läuft.

OK, hatte es dann so gemacht, daß nach 'ner halben Minute die Suche paralell mitläuft (dann braucht die initialisierung "nur" etwa 2 Minuen, aber insgesamt geht es schon schneller)

In einem Testprojekt läuft es jetzt ohne vorherige Suche/Initialisierung und mit 'ner passend optimierteren Dateiliste/Dateiverwaltung und das insgesamt weit über 30% schneller.
Gut, wenn genügend RAM frei ist, dann läuft der zweite Suchdurchlauf schneller, da dann noch alle Verzeichnisse in der WFC rumliegen.
Wobei ich vielleicht erwähnen sollte, daß es sich hier um Laufwerke mit Datei-/Verzeichnisanzahlen im 5- bis 6-stelligen Bereich handelt, wo das doppelte Suchen schon sehr auffällt.
(mit viel Zeit im Rücken würde ich das Ganze dann auch gerne mal auf ein direktes Auslesen der MFT umstellen)

[Guido Eisenbeis]

Zitat:

Zitat von Guido Eisenbeis

... Denn ich tue mir im Moment ein wenig schwer damit, was wo in welchem Thread abgerufen wird, bzw. ankommt.

Hier kam ein Fehler hinzu, den ich finden konnte: Aus mir noch nicht ersichtlichem Grund hat sich in der Projekt-Datei der Eintrag "Application.CreateForm(TForm1, Form1);" 2x befunden!?

Zitat:

Zitat von Daniel G

Der Code basiert im Endeffekt auf dem CodeLib-Eintrag von SirThornberry.

Habe ich bei meiner Recherche hier im Forum schon mitbekommen.

Zitat:

Zitat von Daniel G

...
Eigentlich brauchst du als externe Abhängigkeit nur die Like-Funktion.

Der relevante Teil, der den Code nutzt, findet sich hier:

[delphi]procedure TMediaClass.AddFolderToDatabase(FolderPath: String);
...

Auch das konnte ich schon herrauskristallisieren. Dennoch vielen Dank! (Manchmal hat man einen Hänger ... :drunken: )

Zitat:

Zitat von himitsu

...
Flott? (hab das grad mal auf meine Datenplatte losgelassen)

Dort wird doppelt gesucht
- einmal zur initialisierung, worüber das Ende der ProgressBar bestimmt wird
- und dann NOCHMAL für's Suchen

Die Initialisierung hat ja nichts mit der eigentlichen Suche zu tun. Wie "Rüdiger Hoffmann" schon mal sagt: "Das kann man machen, ... muss man aber nicht!" (Später unten mehr.)

Zitat:

Zitat von himitsu

außerdem wird jede Datei in diesem Label angezeigt, was enorm ausbremst

Mecker, mecker, mecker! ;-) Das gleiche wie oben: Auch diese Funktion ist optional. Man kann sie in diesem Code verwenden, wie in jedem anderen. Dort wird sie genauso bremsen!

Zitat:

Zitat von himitsu

Gerade daß man doppelt suchen muß, ist bei dieser Art des Fortschritts ein Problem.

Ich finde die Initialisierung genial! Wer eine bessere Art weiß, die Grundlage für einen Progress zu erstellen, hat meine Aufmerksamkeit.

Zitat:

Zitat von himitsu

http://www.delphipraxis.net/internal_redirect.php?t=167783&highlight=findallfi les
Dort kann man sich über den Callback anzeigen lassen, wo die Suche sich gerade befindet,

Auch das geht mit Luckys Code.

Zitat:

Zitat von himitsu

worüber sich dann der User in etwa ausdenken kann, wie lange es eventuell noch dauert
(darüber muß man sich zwar in etwa über seine Ordnerstrucktur im klaren sein, aber wer weiß denn nicht, was er auf seinem Rechner hat :angel2: )

Hi, hi, hi, hi, :-D *nett-gemeintes-Lachen* ... Du willst wirklich, dass der User sich ausdenkt, wie lange es noch dauert!? Das ist ja noch besser als die Windows-Progress-Anzeigen, die von 4 Stunden auf 2 Minuten springen! :mrgreen: *nett-gemeint*

Zitat:

Zitat von himitsu

Und sundance bastelt da auch gerade etwas
http://www.delphipraxis.net/internal...t=findallfiles

Werd ich mir ansehen.

Zitat:

Zitat von himitsu

Zitat:

Zitat von Luckie

Aber so weit ich mich erinnere, ist das optional.

Nja, hatte ich bei 'nem eigenem Projekt auch mal so gemacht, weil ich dachte das wäre besser/schöner.
Sobald ich mal Zeit habe dieses zu ändern, wird es bei mir wieder ausgebaut, da es einfach nur nervt, wenn knapp 1,5 Minuten lang eine Initialisierung läuft.

Zum einen ist es optional, zum anderen wirst du um die Initialisierung nicht drum rum kommen. Wenn du direkt mit der Suche beginnst, dauert die auch so lange, beim ersten Durchgang. (Sieh weiter unten.)

Zitat:

Zitat von himitsu

OK, hatte es dann so gemacht, daß nach 'ner halben Minute die Suche paralell mitläuft (dann braucht die initialisierung "nur" etwa 2 Minuen, aber insgesamt geht es schon schneller)

Das wage ich mal zu bezweifen. Denn wie gesagt, die Initialisierung findet statt, auch wenn du sie nicht so nennst. Wenn du zwei Such-Vorgänge parallel laufen lässt, (und die Initialisierung in Luckys Code ist einer,) auf der gleichen physikalischen Platte, dann wird deine Gesamt-Suche *nicht* schneller!

Zitat:

Zitat von himitsu

In einem Testprojekt läuft es jetzt ohne vorherige Suche/Initialisierung und mit 'ner passend optimierteren Dateiliste/Dateiverwaltung und das insgesamt weit über 30% schneller.

Lass uns doch bitte an deinem Code teilhaben.

Zitat:

Zitat von himitsu

Gut, wenn genügend RAM frei ist, dann läuft der zweite Suchdurchlauf schneller, da dann noch alle Verzeichnisse in der WFC rumliegen.

WFC? MFC? VCL?

Zitat:

Zitat von himitsu

Wobei ich vielleicht erwähnen sollte, daß es sich hier um Laufwerke mit Datei-/Verzeichnisanzahlen im 5- bis 6-stelligen Bereich handelt, wo das doppelte Suchen schon sehr auffällt.
(mit viel Zeit im Rücken würde ich das Ganze dann auch gerne mal auf ein direktes Auslesen der MFT umstellen)

Das mit der MFT wäre vielleicht interessant!?


Ok, hier ist das "Weiter unten".

Ich versuche meine Ansichten mal möglichst auf einen kurzen Nenner zu bringen:

1. Bei der Suche kann man rekursiv oder iterativ vorgehen. Was welche Vorteile hat, sei hier mal dahingestellt.

2. Nach Windows 98 werden die Tabellen, die bei einer von uns gemeinten Suche beim ersten Durchlauf gemacht werden, vom Betriebssystem gecacht. (Ob das bei Win 2000 so ist, nehme ich an, bei XP definitiv.)

3.Es spiel keine Rolle, ob man den ersten Durchlauf nun zum Initialisieren benutzt, um bei der ausführlichen Suche einen Progress anzuzeigen, oder direkt für eine Suche. Der erste Duchgang dauert halt länger.

Das sind jetzt keine empierische Erkenntnisse, sondern einfach meine Ansicht. Die wird durch einen Test untermauert, von dem sich im Anhang ein Screenshot der Ergebnisse befindet. Edit: Die Ergebnisse sind gerundet.

Der Test wurde nach eine Windows-Neustart durchgeführt. Nach dem ein Bereich (in diesem Fall ein Laufwerk) durchsucht wurde, dauert jede weitere Suche (insbesondere Initialisierung) nur ein Bruchteil der ersten Suche. Das bleibt so, bis zum nächsten Windows-Neustart.

Guido.


PS: Off-Topic: Guten Rutsch! :party: :cheer: :cheers: :party:


Edit: Hinweis für gerundete Ergebnisse.

[himitsu]

Zitat:

Ich finde die Initialisierung genial! Wer eine bessere Art weiß, die Grundlage für einen Progress zu erstellen, hat meine Aufmerksamkeit.

Es gibt leider nichts besseres, außer man läßt es. :roll:

Will man auf Biegen und Brechen einen Fortschritt mit "ungefährer" Endpunktanzeige, dann geht es nicht anders.


*Meßwerte anguck* und sowas hab ich auch erwartet.
Und genau deswegen laß ich zukünftig diese Art der "Initilisierung" weg und fang direkt mit der Suche an, denn das ist und bleibt das Schnellste.

PS: da in der Realität soeine Suche zum Großteil nicht mehrfach kurz hintereinander gemacht wird und/oder beim weiteren Durchlauf (ein Durchlauf = Init+Suche oder nur Suche) die Ordnerstruktur vermutlich nicht mehr komplett im Cache (WFC = WindowsFileCache) liegt, kann man diesen Fall ignorieren und gleich davon Ausgehn, daß eine Initialisierung/Vorschausuche nicht von der WFC profitieren wird.

Die reine Suche ist demnach langsamer, als die Initialisierungssuche.
(weitere Verarbeitungen, wie z.B. Dateien in Listen einfügen, mal ignoriert)

[Mithrandir]

Im Regelfall reicht es ja auch einfach, eine Progressbar im Marquee-Stil anzubieten. Man beschleunigt so die eigentlich Suche; der User merkt aber dennoch, dass sich was tut.