Announcement

**Hagen Reddmann** · 13.12.2002, 14:10

<pre>

procedure Scan(const Path,FileMask: String; PathList,FileList: TStrings);
var
SR: TSearchRec;
begin
PathList.Add(Path);
if FindFirst(Path + FileMask, faAnyFile and not (faDirectory or faVolumeID), SR) = 0 then
try
repeat
FileList.Add(SR.Name);
until FindNext(SR) <> 0;
finally
FindClose(SR);
end;
if FindFirst(Path + '*.*', faAnyFile, SR) = 0 then
try
repeat
if (SR.Attr and faDirectory <> 0) and
(SR.Name <> '.') and (SR.Name <> '..') then
Scan(Path + SR.Name + '\', FileMask, PathList,FileList);
until FindNext(SR) <> 0;
finally
FindClose(SR);
end;
end; 

function ExpandSlash(const Value: String): String;
begin
Result := Value;
if Result[Length(Result)] <> '\' then
Result := Result + '\';
end; 

procedure FindFiles(const Path,FileMask: String; PathList,FileList: TStrings);
begin
if Assigned(PathList) and Assigned(FileList) and (Path <> '') then
try
PathList.BeginUpdate;
FileList.BeginUpdate;
Scan(ExpandSlash(Path), FileMask, PathList, FileList);
finally
PathList.EndUpdate;
FileList.EndUpdate;
end;
end; 

procedure TForm1.NewSpeedButton1Click(Sender: TObject);
begin
FindFiles('c:\', '*.*', ListBox1.Items, ListBox2.Items);
end; 

</pre>

Obiger Code liest auf meinem rechner innerhalb von 7.5 Sekunden alle Informationen ein. Dein Code ben�tigt daf�r 14 sekunden und findet bestimmte Dateien bzw. Ordner �berhaupt nicht. Wichtig:
<li>beim suchen nach Ordnern reicht NICHT faDirectory aus, da FindFirst() eben keine Bitweise Abfrage der Attribute vornimmt. Ordner die als Versteckt oder System gekennzeichnet wurden werden mit faDirectory alleine nicht gefunden. Es mu� immer (faDirectory or faSystem or faHidden) als Minimum selektiert wwrden. 
<li>der TypCast Boolean(Attr and faDirectory) ist schlichtweg falsch. Durch dummen Zufall ist faDirectory=1 und Byte(True) = 1, deshalb funktioniert deine Code. Bei Boolean(Attr and faHidden) wird er aber fehlschlagen.
<li>Gibt FindFirst(.., SR) = 0 zur�ck, und ausschlie�lich dann, sind die Windows-Finddaten in SR initialisiert und M�SSEN freigebenen werden. D.h. wir m�ssen try finally Blocks nutzen damit keine Memoryleaks verbleiben falls eine Exception auftritt (z.B. Listen sind voll usw.). Desweiteren MUSS FindClose() aufgerufen werden aber NUR wenn FindFirst() erfolgreich ist. Dies ist kein OS-Problem sondern ein Problem in den verschiedenen Delphi RTL Sourcen. In einigen Delphi versionen wird SR durch FindFirst() IMMER initialisiert, egal ob erfolgreich oder nicht. Somit kann FindClose() immer korrekt arbeiten. In anderen Delphi Versionen (glaube D6) wird aber SR eben NICHT initialisiert falls FindFirst() fehlschl�gt. Ein anschlie�ender proforma Aufruf von FindClose() wird eine AV in Kernel32.dll zur Folge haben.
<li>Die TStrings sollten mit Begin/Endupdate die Anzeige Aktulisierung unterbinden. Angenommen TStrings ist ListBox.Items dann liegt dahinter eine extrem inperformante Stringverwaltung des Windows-OS dahinter. TStringList's sollten IMMER bevorzugt werden da sie in diesem Falle extrem schneller sind. Erst wenn die Liste eingelesen wurde sollte mit LiestBox1.Iems.Assign(StringList) angezeigt wwrden. Oder besser noch Memo.Text := StringList.Text was die schnellste Methode ist. 

Gru� Hage

**Hagen Reddmann** · 13.12.2002, 14:51

Statt ListBox.Items habe ich mal eine TStringList benutzt. Sie ben�tigte 5 Sekunden. D.h. ein Speedup von 50 Prozent. Angenommen die nutzt keine TListBox'es sondern ein eigenes Control das auf VCL-TStringLists basiert. Mit obigen Code w�rdest Du deine 2,5 Minuten auf 50 Sekunden reduzieren k�nnen. 
Geht man weiter und nutzt KEINE TStringLists, sondern gro�e Speicherbereiche die die Pfade,Filenamen nacheinander speichern, dann d�rfte das nochmal die zeit reduzieren. Mit TStringList's hat es 5.4 sekunden gedauert, ohne irgendwelche Listen dauerte es 4.5 Sekunden 

Gru� Hage

**Robert Marquardt** · 13.12.2002, 15:20

Eine interessante Frage waere es, ob Threads auf Teilbaeume der Directories beschleunigend wirken

**Hagen Reddmann** · 13.12.2002, 16:37

Nur falls man Mehrprozessoren Systeme hat die mit einem OS genutzt werden das die Job auch unshared auf diese CPU's verteilen kann. Dann m�sste aber auch das Medium das gescannt wird in der Lage sein in parallel zwei Job zu bedienen. Aber das d�rfte wohl unwahrscheinlich sein. Sollte das OS die komplette FAT des Mediums nicht im Speicher halten dann mu� der Zugriff auf die FAT geblockt ablaufen. Da aber das Scannen permanent die FAT lie�t w�rden sich sogar auf einem Mehrprozessorsystem die einzelenen Jobs blockieren. 
Auf Single-CPU Systemen wird eine threaded System noch schlechter bedient. Es stehen pro Minute 100% Kapazit�t zur Verf�gung. Nun w�rden sich 2 Threads diese 100% teilen, d.h. jeder Thread hat 30 -x Sekunden Zeit und kann nur das lesen was 1 Thread in 30-x Sekunden lesen kann. X Zeit wird vom OS zus�tzlich ben�tigt um die beiden Threads zu verwalten. Somit w�rde zwei Thread 60-2x Sekunden ben�tigen was ein Thread in 60 Sekunden schafft. Sollte innerhalb von 60 Sekunden ca. 10ms per Thread zu Verf�gung stehen -1ms f�rs OS, dann ergeben sich 60Sec - 2 * 6Sec = 48 Sekunden. D.h. 2 Threads w�rden in 60 Sekunden das schaffen was ein Thread in 48 Sekunden schafft. Die 10 ms per Thread und 1ms f�r das OS zum Threadmanagement sind weit untertrieben, bzw �bertrieben. Im Normallfalle bekommt dr Thread ca. >0.01 ms Zeit aber ein Threadswitch kostet mehr als 100.000 Taktcyclen. Somit sind Threads hier eine schlechte L�sung. 
Es sei denn, das Medium produziert erheblich lange geblockte Wartezeiten. Dann w�re ein Thread sinnvoll da w�hrend dieser Wartezeit die anderen Threads weiterlaufen k�nnen. Dies ist der zB. Fall bei Kommunikationen (COM,TCP/IP) usw. aber garantiert nicht beim Zugriff auf Festplatten, CD oder Bandlaufwerken. 

Gru� Hagen

PS: Allerdings bei all dieser Theorie, kann man sich gewaltig irren. Z.b. h�ngt obige Annahme in unserem Falle stark davon ab WIE und WO das OS die FAT Infos verwaltet. Sollte es diese im Speicher halten und dieser Speicher kann merhfach in parallel gelesen werden, jo dann k�nnten mehrere Threads auch schneller arbeiten. 
Probieren geht �ber studieren, ich w�rde darauf setzen das die Threads weniger Performance zeigen.

**Fred Ziebell** · 17.12.2002, 11:22

Erstmal extremen Dank....ich vergelt�s im n�chsten Leben

@Hagen:
Das nicht alle Files gefunden werden, war beabsichtigt.
Hidden- und System- und div. andere Files waren f�r mich nicht interessant, da es ich im Prinzip um einen Diskkatalog mit einigen spezifischen Funktionen handelt.
Das bei einlesen das st�ndige Aktualisieren der Listboxen Zeit kostet, war mit klar. Das es sich um SO VIEL Zeit handelt, war mir nicht klar. Im Hauptprogramm sollen tats�chlcch auch keine solchen erscheinen, ich habe diese nur zu Testzwecken benutzt.
Ich werde jetzt deine Routine in mein Hauptprogramm einbinden und und hoffe auf einen "zeitlichen Augenorgasmus".

Vielen Dank
Fred Ziebel

**Fred Ziebell** · 17.12.2002, 17:37

Hi,
@Hagen:

Hmmmm.....Habe deine Routine jetzt ausprobiert. Sie funktioniert tadellos. Aber....

Der Speed-Gewinn ist nicht direkt und reproduzierbar ersichtlich.

Mal abgesehen davon, das wir nat�rlich unterschiedliche MEdien mit unterschiedlichem Inhalt und unterschiedlichen GEschwindigkeiten benutzen, Scheint mir der Windows-Cache(Smartdrive) einen gewaltigen Einflu� auf meine Tests zu haben. Daher mu� ich das ganze wohl eher prozentual bewerten.

Die Prozedur, die zuletzt startet, ist nach einem Drivechange immer die schnellere.....logisch, da sich das zuletzt gelsene Verzeichnis ganz oder teilweise im Cache befinden. Daran �ndert auch ein erzwungener Drivechange nichts.

Allerdings habe ich bei zwei �hnlich gro�en Cd�s (Die Borland DELPHI 5 Cd�S Deutsch und Englisch) deine Routine im Vorteil gesehen( nicht 50% und nicht st�ndig reproduzierbar).

Da deine Routine aber den wesentlich prof. Eindruck macht auch was die Systemsicherheit angeht, werde ich diese f�r meine Zwecke passend umbauen.

Nochmals BEsten Dank.

Gruss Fred Ziebel

**Hagen Reddmann** · 17.12.2002, 19:37

Dank

Announcement

Verzeichnisse schneller lesen

Verzeichnisse schneller lesen

Comment

Comment

Comment

Comment

Comment

Comment

Comment