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)

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.

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?

@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.

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 )

* 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.

Zitat:

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

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

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.

Musste noch bissl ausräumen ... bis vor 10 Minuten hieß es noch Project1/Unit1 und war ein Großtestprojekt mit viel anderem Kleinkram drin
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.
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.

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.

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.

markieren

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

markieren

Code:

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