Scan for Files mit der PPL

[Smiley]

Hallo Delphi Freunde

Ich habe mich etwas mit der PPL (parallel programming library) beschäftigt und damit einige Gehversuche gestartet.
Am Besten hat mir das CodeRage 2016 Session6 Video von Olaf Monien gefallen.
Die Embarcadero Hilfe zu PPL habe ich mir auch angesehen.
Am leichtesten verstehe ich es aber durch Beispiele.
Als Beispiel zum ausprobieren habe ich mir folgendes ausgedacht:
Einlesen von Verzeichnissen (FindFirst,FindNext) und messen der Geschwindigkeit bei mehreren Tasks.
Dass hier eine Begrenzung durch das Filesystem gegeben ist ist mir klar, ich wollte herausfinden wie weit threading hier sinnvoll ist.
Es macht natürlich einen Unterschied ob ich auf eine Festplatte,SSD oder LAN zugreife. Eventuell auch auf mehrere davon gleichzeitig, was eine parallelisierung sinnvoller macht.

Beispiel Verzeichnisse einlesen:
Ich habe ein Startverzeichnis mit 10 Unterverzeichnissen, diese haben ebenfalls Unterverzeichnisse, insgesamt 100 UnterUnterverzeichnisse und einige tausend Dateien.
Mit Filesearch sollen alle Verzeichnisse mit maximal 3 Threads gelesen werden.
Wenn ein SubSub..Dir beendet wurde, soll die Trackbar erhöht werden. Trackbar.max ist schon ein Problem, da ich noch nicht weiß wieviele SubDirs ich habe.
Eventuell das mit readDirs erst mal vorab einlesen ? wenn das nicht schon zu lange dauert.
Wie könnte man das am effektivsten lösen ?

Das beigelegte BeispielProjekt ist ein Anfang dazu. Die folgenden wichtigen Punkte sind aber noch nicht drin:

1. Threadpool (TThread.Queue) benutzen um nur eine begrenzte Anzahl von Tasks gleichzeitig laufen zu lassen ohne parallel.for ( MaxThread:=3; )
2. Thread Events benutzen (OnTerminate) kann ich darin auf threadvariablen zugreifen ? (ThreadStatus,threadID)
3. Kann ich die StopWatch im Thread benutzen um die threadzeit zu messen ?
4. System.Monitor.Enter(self); try inc(Taskcounter); finally System.Monitor.Stop(self); end; Ist das wie Synchronize um Variablen im Haupthread zu verändern. Welche Vorteile bringt das ?
5. Den Status der Threads, aus dem MainThread, lesen um festzustellen welcher Thread noch läuft. Kein WaitFor.. ich will im MainThread derweil noch andere Dinge machen.
6. Trackbar.Position bewegen wenn ein Thread seine Aufgabe erfüllt hat.
7. Wie kann ich durch einen Cancel Button alle Tasks abbrechen ?

Ich benutze Delphi 10.4 Architect auf Windows 10 1909. TMS AllAccess vorhanden. (In Bereich Filesearch oder Tasks hat TMS aber glaube ich nichts spezielles enthalten)

[himitsu]

Vor allem bei richtigen HDDs, wo noch nichts im Cache ist, macht man sich so eher langsamer, als schneller.
Und auch bei SSDs ist ein Thread mit vollem Tempo nicht viel langsamer, als zwei Threads mit halben Tempo, bzw. Mehr mit noch kleinerem Bruchteil.

Besser als parallel ist hier die richtig Wahl der Listenfunktionen, welche kein elendlig langsames "Caching" und Sortieren betreiben, wie die normalen FindFirst/FindFirstFile.

[DieDolly]

Zitat:

Besser als parallel ist hier die richtig Wahl der Listenfunktionen, welche kein elendlig langsames "Caching" und Sortieren betreiben, wie die normalen FindFirst/FindFirstFile.

Hättest du hierfür ein Beispiel wie man mit deiner Idee ein Verzeichnis mit allen Unterverzeichnisen rekursiv durchsucht und in einer Liste packt?

[Smiley]

@himitsu Von diesen Listenfunktionen habe ich noch nichts gelesen, kannst Du das näher beschreiben.

Dass der Einwand kommt, dass es nicht sinnvoll ist Threading mit Dateifunktionen zu verknüpfen habe ich schon kommen sehen, das ist mir auch bewusst, arbeite aber gerade damit und habe das als Beispiel genommen.
Der Weg ist das Ziel.
Lassen wir also den Sinn dieses Beispiels mal weg und sehen ob ich was zu PPL lernen kann.
Ich habe schon so viel über die Möglichkeiten und Probleme des PPL gelesen und wollte das jetzt mal umsetzen.
Dieses Beispiel ist immer noch besser als die Sleep Funkionen die sonst so verwendet werden.

[himitsu]

Leider noch nicht, hatte vor 2 Wochen mal wieder einen Test dazu angefangen, aber Zeitmangel ....
Hatte angefangen eine kleine Testanwendung zu schreiben, um da mal alle Möglichkeiten gegenüberzustellen und zu vergleichen,
mit lokaler Festplatte und SMB zum NAS, frisch ohne Cache und mit gefülltem Cache. (mit über 1,5 Millionen Dateien in knapp 6 TB und viel zu vielen kleinen Verzeichnissen und ein paar viel zu großen Verzeichnissen ... geht mal mit dem Explorer ins WinSxS :stupid:)

* RawDaten der Platte auslesen und Dateisystem selber parsen (schön schnell, aber das will Niemand, außer Forensikern und Datenrettern)
* MasterFileTable auslesen auch schnell, aber dafür braucht man höhere Rechte, also nicht praktikabel
* Shell Interfaces : IEnumShellItems, bzw. das alte IShellFolder ... weiß noch nicht (denke es sollte langsamer sein, aber wäre nicht überascht es wäre das nicht)
* TDirectory.GetFiles nutzt FindFirst (wobei gier die Funktionen/Parameter/Rückgaben teils etwas "unglücklich" sind, wenn man das "effektiv" nutzen und nichts doppelt behandeln)
* FindFirst nutzt FindFirstFile, mit bissl teilweise blödsinnigem Overhead (alles Suchen und dann filtern ... kann auch sein, das ich es grade mit GetFiles verwechsel)
* FindFirstFileEx statt FindFirstFile geht schon besser (mit den richtigen Optionen)
* am Besten lief es mit der Native-API, was langsam nutzbar ist, seitdem Microsoft anfängt die offiziell zu Dokumentieren und es somit nicht mehr per se heißt "die ist intern und geheim und kann sich jederzeit unvorhersehbar ändern oder die 'Hacker' haben die API falsch entschlüsselt"

Vielleicht such dich später mal meinen Testcode raus ... Mal sehn, ob ich mit dem Fingerabdrucksensor noch vor Sonntagabend fertig werde und mich dann langweile.

[DieDolly]

Zitat:

* FindFirstFileEx statt FindFirstFile geht schon besser (mit den richtigen Optionen)

Die sind deiner Meinung nach? :thumb: (FindExInfoBasic, FIND_FIRST_EX_LARGE_FETCH ?)
Findet FindFirstFileEx, wie der Name nur sagt, nur Dateien?

[himitsu]

Ja, z.B.

Nee, es findet "Einträge" im Dateisystem, also Dateien, Verzeichnisse, ...
Auf Verzeichnissen vom Unix/Linux (gibt es jetzt ja auch im Windows und über Netzwerkfreigaben), da kann eine "Datei" ALLES sein, auch eine Hardware oder ein Programm.

Windows : ALLES ins ein Fenster
Linux : ALLES ist eine Datei
Postgres : ALLES in eine Tabelle
:stupid:

[Daniel]

Bedenkt bitte, dass Ihr Euch hier in einem Thema zu "PPL und Dateisystem" befindet.

[DieDolly]

Für einen großen test hast du keine Zeit. Kannst du ein Minimalbeispiel posten damit man das mit dem PPL-Zeug vergleichen kann?

[Smiley]

Ich habe noch etwas herumprobiert um die Tasks abbrechen zu können, das funktioniert leider nicht.
Habe auch eine Verzeichnisauswahl eingebaut, ab der gesucht wird.
Bei kleinen Mengen von Dateien geht es recht schnell und man sieht die Probleme nicht.
Ab 10000 Dateien und mehr kommt aber schon "keine Rückmeldung" und Button "Abbrechen" führt auch nichts aus, da das Programm zu beschäftigt ist.
Das auflisten der Dateien kommt auch erst ganz zum Schluss.
Selbst das warten auf die Tasks bringt nichts.
Die Variable FileAnz wird nicht hochgezählt.

Das neue File ist hier angehängt.
Finde den ändern Button für den ersten Beitrag nicht.

Ich hoffe es kann sich noch mal jemand damit beschäftigen.
Im Projekt werden nur Standardfunktionen verwendet, sollte überall laufen.

Schönes Wochenende noch und habt Spass bei dem schönen Wetter.

[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;

[DieDolly]

Zitat:

Ich habe mal gerade Himitsus Vergleich ausprobiert und muss etwas einschränkend sagen, dass mein System offenbar sehr schnell ist:

Scheinbar hat deine NVME hier Nachteile. Ich dachte immner, die teuren Dinger sind so schnell.

Verglichen zu einer SATA-SSD mit gutem DRAM-Cache:

*
FindFirstFileEx Large first : count 581280, seconds 0,5515497‬
FindFirstFileEx Large second : count 581280, seconds 0,5521473‬
FindFirstFileEx Large *.txt : count 581280, seconds 0,6303993‬
*

Mit gelöschtem Cache sollte es noch immer unter 7 Sekunden liegen.

[Benmik]

Da hast du recht, meine NVME ist eine ohne DRAM-Cache, ich fand den Aufpreis für z.B. eine EVO nicht gerechtfertigt. Maßgeblich ist aber eigentlich das Einlesen nach Neustart, bei allem anderen schrumpfen die Zeiten sowieso gewaltig. Dass du beim ersten Einlesen unter 7 sec bleibst, möchte ich erstmal sehen.

[himitsu]

Es kommt nicht nur auf de Datenträger an.

Ich dachte immer die HDD im alten PC meiner Mom sei sau langsam.
Als der PC mal kaputt war (Mainboard im Arsch), da war die plötzlich relativ flott, als sie an meinem PC hin. (da mochten sich HDD, Controller, Board, irgendwas wohl nicht)

[DieDolly]

Zitat:

(da mochten sich HDD, Controller, Board, irgendwas wohl nicht)

Gehört zwar nicht hier her, aber Mainboards erzeugen einen vernachlässigbaren Geschwindigkeitsvorteil in Zusammenhang mit Festplatten (bei normalen PCs).
Wenn eine SSD über PCIe dran hängt und gleichzeitig noch eine GPU im 16er Slot, dann würde man eventuell etwas merken.

Einzig und allein mess- und fühlbar machen hier den Unterschied der RAM und die CPU.

[Benmik]

Ich habe hier neuerdings eine NVME von Western Digital die ca. 2,5 GB/s liest und 2 GB/s schreibt. Das fand ich völlig genug, auch ohne DRAM. Darunter ist auch TDirectory.GetFiles schnell. Ich meine, 10 Sekunden für 500.000 Dateien, das ist doch abartig. Die MFT ist aber auch bei langsamen Rechnern schnell.

[backdraft]

Zitat:

Zitat von Benmik (Beitrag 1467971)

Ich habe hier neuerdings eine NVME von Western Digital die ca. 2,5 GB/s liest und 2 GB/s schreibt. Das fand ich völlig genug, auch ohne DRAM. Darunter ist auch TDirectory.GetFiles schnell. Ich meine, 10 Sekunden für 500.000 Dateien, das ist doch abartig. Die MFT ist aber auch bei langsamen Rechnern schnell.

Benutzt Du einen einen Code oder irgendwas, was man kaufen kann um den MFT auszulesen?