Viele Dateien performant einlesen

[Dejan Vu]

Zitat von Union:

Du könntest aber mehrere Threads zur Verarbeitung einsetzen, vielleicht wird es dann schneller.

Auch bei einer SSD? Bei ner HDD ist der Lesekopf doch der Flaschenhals,...

[himitsu]

Bei einer SSD kommt es auf die Controller an, wie viele Leseoperationen dort parallel behandelt werden können. Und auch auf die anderen Caches, wie und ob sie beim MultiThreading die Daten verwalten/blocken.

Bei Festplatten macht ein paralleles Lesen alles viel Schlimmer, da der Lesekopf dort womöglich/bestimmt mehr hin und her rennen muß, als wenn man das sequentiell lesen würde ... Besser wird nichts, höchstens langsamer. (außer die Daten liegen bereits im Cache)



Das Einzige was man noch machen kann, ist die Cache zu umgehen. (FILE_FLAG_NO_BUFFERING)
Beim "ersten" Laden ist es dann einen Hauch schneller, wenn andere Daten nicht erst aus dem Cache rausgeworfen werden müssen.
Aber beim zweiten Durchgang ist es dann langsamer, da die Dateien ja nicht im Cache gelandet sind.
Allerdings ist es insgesamt dennoch schneller, wenn man mehr Daten lesen will, als freier RAM zur Verfügung steht.

Deine Dateien sind aber auch so klein, daß vermutlich FILE_FLAG_SEQUENTIAL_SCAN nichts bringt, da es impliziet schon gemacht wurde, vorallem wenn die Sektorgröße Clustergröße groß genug ist.


MMF ist eher für RandomAccess geeignet, oder wenn man direkt in dem speicher mit Pointern rumrennen will, ohne einen eigenen Buffer verwalten zu müssen.
Und bei so kleinen Dateien bringt das keinen großen Vorteil. Wobei auch und vorallem hier die Datei erst (nahezu unkontroliert) vom windows erst in den WFC geladen werden muß, dessen Speicher dann windows in deinen virtuellen RAM mappt/verlinkt.

[user0815]

Hatte hier im Forum mal was von einem "BULK INSERT" gelesen, habe allerdings keine Ahnung (da noch nie gemacht) ob dieser auch für viele Dateien geeignet ist.

[mkinzler]

Bulkinsert ist eine Verfahren für den schneller Import in einen (MS)SQL-Server.

[himitsu]

Zitat von mkinzler:

Bulkinsert ist eine Verfahren für den schneller Import in einen (MS)SQL-Server.

Aber auch dieser der schnelle Insert wird die Dateien einzeln einlesen müssen.

Das Einzige was ihn noch einen Hauch schneller machen könnte, ist dann die Behandlung der eingelesenen Daten.


Seit Delphi 2009 arbeiten StringStream, StringList und co. noch mit einem zusätzlichem Zwischenschritt, wo das Encoding auf Unicode umgewandelt wird.

[Uwe Raabe]

Zitat von himitsu:

Das Einzige was ihn noch einen Hauch schneller machen könnte, ist dann die Behandlung der eingelesenen Daten.


Seit Delphi 2009 arbeiten StringStream, StringList und co. noch mit einem zusätzlichem Zwischenschritt, wo das Encoding auf Unicode umgewandelt wird.

Aber Günther sagt doch, daß es beim zweiten Mal deutlich schneller geht. Somit kann man mit einer Optimierung des Post-Read-Vorgangs auch nur einen Teil dieser Zeit vom zweiten Lesevorgang einsparen. Das halte ich für ziemlich ineffizient.

[Der schöne Günther]

Ich muss zugeben, keine sonderlich ausführlichen Tests gefahren zu haben. Zwei mal myStringList.ReadFromFile(..) auf die exakt gleiche Datei hintereinander. Das zweite mal geht praktisch sofort. Das meinte ich.

In den Innereien von TFileStream habe ich jetzt nicht gewühlt...

[Blup]

Ich schlage vor du änderst das Konzept.
Fass die z.B. 5000 Dateien zu einer zusammen, die im ersten Schritt importiert wird.
Sollte sich eine der Dateien nachträglich ändern, wird die geänderte Version zusätzlich in das Verzeichnis gespeichert.
Im zweiten Schritt werden diese Änderungen importiert.
Nützlich ein optionaler dritter Schritt, der die Datei mit allen Änderungen wieder erstellt und die dann überflüssigen Einzeldateien löscht.
Alternativ zum Löschen kann man auch mit den Dateiattributen(Archiv) oder Änderungszeitpunkt arbeiten.