FindFirst, FindNext alternative
-
Hallo Zusammen,
ich lese Verzeichnisse und Unterverzeichnisse mit FindFirst und FindNext aus.
Dies funktioniert bei lokalen Platten (IDE, SATA, USB) auch recht super und schnell.
Doch wenn ich auf einen Netzlaufwerk zugreife, habe ich das Gefühl, dass es durch irgendetwas ausgebremst wird. Dies wird auch durch den Versuch de Aufruf der Eigentschaften von Windows des Verzeichnis bestätigt. Dort zählt er rasant die Dateien und Verzeichnisse zusammen. Das könnte man fast schon mit Bummelbahn und Flugzeug gegeneinander vergleichen.In meiner Rekursivenfunktion füge ich meine Einträge einer TStringList zu. Dabei ermittel ich noch die Dateigröße via GetFileSize für Dateien jenseits der 4GB Marke.
Gibt es dafür eine Alternative? Wie macht es denn Windows? Benutzen die Index und was machen die mit Dateien welche dann nicht indiziert sind?
Vielleicht kennt der eine oder andere ja eine passable Lösung für mein Problem.
Beste Grüße
Mastermind
-
Ich kenne dein Problem, geht mir genauso.
Nur habe ich das Gefühl, daß Windows (z. B. der Explorer) es auch nicht anders macht. Verzeichnisse mit sehr vielen Dateien dauern im Netz sehr lange.
Es scheint auf die Qualität des Netztwerks anzukommen, habe z. B. das Gefühl, daß durch einen anderen Switch die Sache deutlich schneller geworden ist.
Bei mir ist es so, daß ich aus einer Liste von Dateien ein bestimmte heraussuchen muß. Es handelt sich immer um eine neuere Datei, je mehr Dateien im Verzeichnis sind, umso länger dauert es.
Daher würde mir helfen, wenn ich von hinten suchen könnte, mit FindLast und FindPrevious, was es aber in der WinAPI wohl nicht gibt.
-
Hallo
Du kannst natürlich noch auf die WinAPI-Funktionen FindFirstFile und FindNextFile umsteigen, damit reduzierst du ein bißchen Overhead, da die VCL intern auch nur diese Funktionen aufruft. Alternativen oder Optimierungen dazu sind mir nicht bekannt, da hast du vielleicht im WinAPI-Forum mehr Glück.
Das extra GetFileSize dürfte überflüssig sein, da TSearchRec bereits schon die Eigenschaft Size hat. Auch das Ergebnis der WinAPI-Funktionen beinhaltet die Dateigröße schon.
bis bald
akari
-
akari schrieb:
Das extra GetFileSize dürfte überflüssig sein, da TSearchRec bereits schon die Eigenschaft Size hat.
Ich nutze GetFileSize damit ich auch die richtige Dateigröße (Dateien > 4GB) ermittele. Das klappte mit size nämlich nicht.
Die WinAPI Funktionen werde ich dann mal ausprobieren. Vielleicht bringen die ja doch gerade im Netzwerk Performance.
W. Posur schrieb:
je mehr Dateien im Verzeichnis sind, umso länger dauert es.
Dies kann ich bestätigen. Das ist wirklich erschreckend wie langsam auf einmal das ganze wird.
-
Hallo
akari schrieb:
Das extra GetFileSize dürfte überflüssig sein, da TSearchRec bereits schon die Eigenschaft Size hat.
Ich nutze GetFileSize damit ich auch die richtige Dateigröße (Dateien > 4GB) ermittele. Das klappte mit size nämlich nicht.
Gut, das habe ich nicht beachtet. Aber das ist nur einer weiterer Grund auf die WinAPI-Funktionen umzusteigen. Denn im Gegensatz zu TSearchRec wird dort die Dateigröße nicht als 32 Bit übergeben, sondern als 2x32 Bit (nFileSizeHigh und nFileSizeLow). Das kannst du einfach zu einem 64-Bit Integer zusammenfassen.
bis bald
akari
-
akari schrieb:
Hallo
akari schrieb:
Das extra GetFileSize dürfte überflüssig sein, da TSearchRec bereits schon die Eigenschaft Size hat.
Ich nutze GetFileSize damit ich auch die richtige Dateigröße (Dateien > 4GB) ermittele. Das klappte mit size nämlich nicht.
Gut, das habe ich nicht beachtet. Aber das ist nur einer weiterer Grund auf die WinAPI-Funktionen umzusteigen. Denn im Gegensatz zu TSearchRec wird dort die Dateigröße nicht als 32 Bit übergeben, sondern als 2x32 Bit (nFileSizeHigh und nFileSizeLow). Das kannst du einfach zu einem 64-Bit Integer zusammenfassen.
bis bald
akariin TSearchRec ist TWin32FindData enthalten - MIT 64bit Size!
Gruss
Frank