Servus, opendir() hat gerade >45 min gebraqucht bis es mir die erste Datei übergeben hat. Ok, es sind ca 1,15 Mio Files aber was macht das da so ewig ?
wird wohl eine (sortiert)? liste mit den 1,15 Mio. FIles anlegen (hast schon findfirst/findnext probiert, das wäre "üblicher")
Gast
#3014177
Joachim Drechsel schrieb: > k, es sind ca 1,15 Mio Files aber was macht das da > so ewig ? er liest glaube ich von jeder Datei die eigenschaften aus.
Wäre mal einen Versuch wert. Den Windows-Explorer hauts komplett raus. Ich vermute auch, opendir() baut erst eine Liste auf. Im Taskmanager war aber von einem dann zu vermutenden üppigen Speicherverbrauch nichts zu sehen ... Zum Glück läuft das Programm (vermutlich) nur einmal. Altdaten einlesen halt. opendir() war mal wieder Gewohnheit ;) Mich würde nur mal interessieren was opendir() so alles aufruft bis es im Win32 API landet. Ich kann mir schon vorstellen, es ist im Emdeffekt das gleiche wie bei findfirst() (das gab es doch schon als DOS-Call direkt ?).
Gast
#3014192
Joachim Drechsel schrieb: > Mich würde nur mal interessieren was opendir() so alles aufruft > bis es im Win32 API landet. einfach filemon mitlaufen lassen und schon wüstest du es.
Ich meine die Aufrufe in der Lib.
opendir entstammt dem Unix/Posix API und solcher Lib-Code versucht folglich, sich diesem API entsprechend zu verhalten. In Windows kann es bedeuten, dass es bei riesigen Directories ineffizient arbeitet. Woher kommt diese opendir Funktion denn überhaupt?
Gast
#3014220
Joachim Drechsel schrieb: > Ich meine die Aufrufe in der Lib. diese werden aber auf api aufrufe an BS umgesetzt und sehr viele davon sieht du im filemon.
opendir() ist eine Libraryfunktion des Watcom C. Ich suche mal nach filemon, anscheinend hat MS da etwas neues ...
Gast
#3014225
> Ich suche mal nach filemon, anscheinend hat MS da etwas neues ...
keien ahnung ob man filemon noch downloaden kann, das neu ist der
procmon dieser ist aber irgendwie langsam bei beenden vom trace.
Joachim Drechsel schrieb: > Ok, es sind ca 1,15 Mio Files Eine flache Directory mit derart vielen Files ist nicht wirklich angenehm zu verwenden. Das dürfte dir mittlerweile auch aufgefallen sein. Besonders fies wird es allerdings, wenn die Filenamen nicht in 8.3-Format passen und das Filesystem in alter Tradition zusätzliche 8.3-kompatible Filenamen anlegt.
Gast
#3014283
A. K. schrieb: > Besonders fies wird es allerdings, wenn die Filenamen nicht in > 8.3-Format passen und das Filesystem in alter Tradition zusätzliche > 8.3-kompatible Filenamen anlegt. NTFS macht das aber im standard nicht. Und auf Fat32 passen so viele Datein gar nicht daruf. Also gibt es diese Problem gar nicht.
Gast
#3014286
Peter II schrieb: > A. K. schrieb: >> Besonders fies wird es allerdings, wenn die Filenamen nicht in >> 8.3-Format passen und das Filesystem in alter Tradition zusätzliche >> 8.3-kompatible Filenamen anlegt. > > NTFS macht das aber im standard nicht. Und auf Fat32 passen so viele > Datein gar nicht daruf. Also gibt es diese Problem gar nicht. sorry, es ist sogar andersrum. Im Standard wird noch 8.3 geschrieben - leider ru spät nachgelesen.
A. K. schrieb: > Eine flache Directory mit derart vielen Files ist nicht wirklich > angenehm zu verwenden. Das dürfte dir mittlerweile auch aufgefallen > sein. Es war nicht meine Idee :-)))
Gast
#3015321
Joachim Drechsel schrieb: > Es war nicht meine Idee :-))) Alter Novell-Server? Da hat man das gern so gemacht, es wurde sogar herausgestellt, dass Novell mit irre vielen Dateien besonders gut zurechtkam, geholfen hat es nicht. Gruss Reinhard
Mein letztes war NetWare 4.11. Nie Probleme. Bis auf NLMs mit Ausgabe auf den Bildschirm: Einmal über den Rand und CRASH ;)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.