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")
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 ?).
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.
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?
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 ...
> 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.
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.
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 :-)))
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 ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.