Scan for Files mit der PPL

[himitsu]

Musste noch bissl ausräumen ... bis vor 10 Minuten hieß es noch Project1/Unit1 und war ein Großtestprojekt mit viel anderem Kleinkram drin :oops:
und fehlt halt noch bissl was, wie z.B. die MFT und den FileCache vor den ersten Durchläufen zu leeren.
Drum wird hier das Memo gespeichert, um zwischen den Aufrufen den Rechner neu zu starten. :stupid:
Und bei "all" wird jeweild der erste Durchlauf übersprungen. (weil ja ohne ClearCache)

PS: Denn RAM zu überfüllen und den Cache so loszuwerden, wurde nicht eingebaut, da es nicht nur diesen Cache löscht und das Ergebnis etwas verfälscht.

[edit]
Boar eh, selbst im ClassicMode ist Delphi 10.4 echt ein Grauß, obwohl hier "garnichts" auch nur halbwegs Komisches verwendet wurde.
Zuletzt in 10.3.3 sah das noch nicht so aus, obwohl dort noch ganz anderer kranker Scheiß in der Unit drin war.



Außer jeweils dem ersten Post im UserProjekte-Unterforum kann Beiträge nur 1440 Minuten (24 Stunden) lang bearbeiten.

[Smiley]

Hier die Ergebnisse, die bei mir nach 2 Neustarts rauskommen.



TDirectory.GetFiles second : count 475349, seconds 16,1788474
TDirectory.GetFiles *.txt : count 4677, seconds 15,302593

SysUtils.FindFirst second : count 475349, seconds 14,8854405
SysUtils.FindFirst *.txt : count 4677, seconds 14,8693349

FindFirstFile second : count 475349, seconds 14,5398242
FindFirstFile *.txt : count 4677, seconds 14,8291518

FindFirstFileEx Two second : ignored
FindFirstFileEx Two *.txt : API does not support Directory-Filter

FindFirstFileEx second : count 475349, seconds 13,8974147
FindFirstFileEx *.txt : count 4677, seconds 13,9862744

FindFirstFileEx Large second : count 475349, seconds 14,5632557
FindFirstFileEx Large *.txt : count 4677, seconds 14,4209989


TDirectory.GetFiles second : count 475528, seconds 16,3475776
TDirectory.GetFiles *.txt : count 4674, seconds 15,2251856

SysUtils.FindFirst second : count 475528, seconds 14,7077626
SysUtils.FindFirst *.txt : count 4674, seconds 15,0170326

FindFirstFile second : count 475528, seconds 14,5263006
FindFirstFile *.txt : count 4674, seconds 14,6547686

FindFirstFileEx Two second : ignored
FindFirstFileEx Two *.txt : API does not support Directory-Filter

FindFirstFileEx second : count 475528, seconds 13,9469684
FindFirstFileEx *.txt : count 4674, seconds 13,9870103

FindFirstFileEx Large second : count 475528, seconds 14,5177057
FindFirstFileEx Large *.txt : count 4674, seconds 14,4392123



Das FindFirstFileEx kommt hier ganz gut weg.
Das Maskieren bringt keine großen Vorteile, da ja trotzdem alle Dateien gelesen werden müssen.
MasterFileTable könnte noch mal spannend werden.
So schlimm ist der Unterschied aber auch nicht, 1 bis 2 Sekunden Unterschied bei knapp 500Tausend Dateien ist jetzt nicht so schlimm wie ich es erwartet habe.

[himitsu]

Das Auflisten von Verzeichnissen mit sehr vielen Dateien ist vor allem eine große Bremse, bei diesen APIs.
FIND_FIRST_EX_LARGE_FETCH ist schon eine Verbesserung und noch mehr sollte mit der Native-API gehn, wo dann mit einem Zugriff gleich mehrere/alle Verzeichniseinträge gelesen werden können und wo die Sortierung und Synchronisierung entfält.

Dann bremst eben die Anzahl der Verzeichnisse. (viele kleine Zugriffe)

Aber alles kommt auch drauf an was man wann und wie mit den gefundenen Dateien macht.
Wer während der Dateisuche auch gleich eine "aufwändigere" Verarbeitung macht, dem reicht auch eine langsamere SuchAPI.

Und bei "diesem" Gesamttest bekommt kann man nur die APIs vergleichen, aber leider fehlt da der Anteil ohne den FileCache, welcher einen großen Einfluß hat.
Außer bei vollem, bzw. zu wenig RAM, wo der Anfang schon wieder aus dem Speicher flog, wenn man am Ende angekommen ist.
Ist das Verzeichnis aber oft im Zugriff und der Cache fast immer geladen, dann macht es so erstmal kaum Unterschiede.

Eventuell könnte man auch noch selbst einen Suchindex anlegen oder den Index der Windows-Suche verwenden.
Aber wenn ich mal was großes Suche, dann ist oft der Cache leer und es existiert kein (aktueller) Index.

Code:

C:\

TDirectory.GetFiles first      : count 723419, seconds 75,397297
TDirectory.GetFiles second : count 723419, seconds 26,8274681
TDirectory.GetFiles *.txt    : count 4591, seconds 24,1096554

SysUtils.FindFirst first      : count 723437, seconds 69,8219776
SysUtils.FindFirst second : count 723438, seconds 23,0809693
SysUtils.FindFirst *.txt    : count 4591, seconds 23,23307

FindFirstFile first      : count 723440, seconds 71,4561471
FindFirstFile second : count 723440, seconds 23,4150029
FindFirstFile *.txt    : count 4587, seconds 23,3955506

FindFirstFileEx_Two first      : ignored
FindFirstFileEx_Two second : ignored
FindFirstFileEx_Two *.txt    : API does not support Directory-Filter

FindFirstFileEx first      : count 723453, seconds 54,2829479
FindFirstFileEx second : count 723453, seconds 21,1287913
FindFirstFileEx *.txt    : count 4587, seconds 21,7199787

FindFirstFileEx_Large first      : count 723458, seconds 46,3399186
FindFirstFileEx_Large second : count 723458, seconds 22,0639785
FindFirstFileEx_Large *.txt    : count 4587, seconds 21,9976944

FindFirstFileEx_Large first      : count 723493, seconds 45,5296624
FindFirstFileEx_Large second : count 723498, seconds 24,5367251
FindFirstFileEx_Large *.txt    : count 4587, seconds 22,7366019

Code:

TDirectory       75  26
FindFirst        70  23
FindFirstFile    70  23
FindFirstFileEx  55  21
EX_LARGE_FETCH   45  22

[Benmik]

Ich habe mich in den letzten Wochen sehr mit der MFT beschäftigt. Typisches Ergebnis: 102.000 Dateien und 1.100 Verzeichnisse mit Basisinformationen in 700 msec (bei neu gestartetem Rechner, beim zweiten Einlesen etwa 250 msec., von NVME gelesen).

Himitsu meint, Auslesen der MFT kommt wegen der notwendigen Adminrechte nicht in Frage. Das möchte ich doch mal hinterfragen. Wenn man selbst das Programm anwendet, ist das sowieso egal. Aber auch sonst frage ich mich, was daran so schlimm sein soll, wenn das Programm mit Adminrechten läuft. Hardware-Diagnostik-Tools laufen immer nur mit Adminrechten. Es ist wie mit den verrufenen ADS: Man verbannt doch keine Messer aus der Küche, weil man damit jemand erstechen kann. Was ist schlimm an einem mit Adminrechten laufenden Programm, das nichts Böses tut?

Eine andere Möglichkeit ist auch, es dem Anwender zu überlassen ("Möchtest du lieber 0,7 oder 70 Sekunden warten?") oder den MFT-Teil nur bei Bedarf zu starten (einige meiner Fragen in letzter Zeit zielten ja in diese Richtung). Zu bedenken ist auch, dass man nach einmaligem Einlesen ja den gesamten Datenbestand der Platte hat und danach alle Filtervorgänge in Millisekunden ablaufen (wenn's sein muss, müsste man zwischenzeitliche Dateiveränderung über das USN-Journal berücksichtigen).

Natürlich geht das Auslesen der MFT nicht in allen Szenarien. Aber da ich ja - wie alle hier - Everything benutze, kommt ein grundsätzlicher Verzicht darauf für mich nicht (mehr) in Frage.

[DieDolly]

Zitat:

Himitsu meint, Auslesen der MFT kommt wegen der notwendigen Adminrechte nicht in Frage. Das möchte ich doch mal hinterfragen. Wenn man selbst das Programm anwendet, ist das sowieso egal. Aber auch sonst frage ich mich, was daran so schlimm sein soll, wenn das Programm mit Adminrechten läuft.

Netzlaufwerke kann man mit Adminrechten vergessen.

Funktioniert euer MFT-Code auch Ext4- oder XFS-formatierten Festplatten?

[Benmik]

Zitat:

Zitat von DieDolly (Beitrag 1467942)

Netzlaufwerke kann man mit Adminrechten vergessen.

Ja, vor allem das hatte ich mit "nicht in allen Szenarien" gemeint.

Zitat:

Zitat von DieDolly (Beitrag 1467942)

Funktioniert euer MFT-Code auch Ext4- oder XFS-formatierten Festplatten?

Ich kenne Ext4 oder XFS nur vom Namen her, haben die eine MFT? Also nein, gemeint ist natürlich NTFS.

[DieDolly]

Immer mehr Gründe, über die ganz einfachen, bereits vorhandenen Implementierungen zu gehen.
Ob das jetzt 23 oder 22 Sekunden dauert, ist dabei vollkommen egal und rechtfertigt nicht die Zeit die man investieren muss, um FindFirstFileEx und alle anderen umzusetzen.

[Benmik]

Ich habe mal gerade Himitsus Vergleich ausprobiert und muss etwas einschränkend sagen, dass mein System offenbar sehr schnell ist (Rechner wurde für jeden Lauf neu gestartet):

Delphi-Quellcode:

FindFirstFileEx Large first      : count 515886, seconds 7,3693847
FindFirstFileEx Large second : count 515886, seconds 3,1792396
FindFirstFileEx Large *.txt    : count 3389, seconds 3,2297414

TDirectory.GetFiles first      : count 515887, seconds 9,9470432
TDirectory.GetFiles second : count 515887, seconds 3,6347474
TDirectory.GetFiles *.txt    : count 3390, seconds 3,1972282

FindFirstFile first      : count 515887, seconds 8,8944801
FindFirstFile second : count 515887, seconds 3,0955637
FindFirstFile *.txt    : count 3390, seconds 3,2385233

FindFirstFileEx first      : count 415328, seconds 16,7086252
FindFirstFileEx second : count 415328, seconds 8,9083499
FindFirstFileEx *.txt    : count 2158, seconds 8,9315763

Die Implementierung von "MasterFileTable" hat mir besonders gut gefallen; die ist auch für den Anfänger richtig gut verständlich!:thumb:

[Smiley]

Ich benötige beim Einlesen auch das AccessDate, ModifyDate usw. da nutzt das schnelle suchen dann eh nichts oder kann man das mit diesen Befehlen auch gleich einlesen ?

[Benmik]

Dabei ist (neben für die MFT wichtigen Informationen):

Delphi-Quellcode:

Filename;
Fragmented;
RealFileSize;
AllocatedFileSize;
CreationTime;
WriteTime;
ReadTime;
NumHardlinks;