Viele Dateien performant einlesen

[mkinzler]

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

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1257248)

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:

Zitat von himitsu (Beitrag 1257249)

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

Delphi-Quellcode:

myStringList.ReadFromFile(..)

auf die exakt gleiche Datei hintereinander. Das zweite mal geht praktisch sofort. Das meinte ich.

In den Innereien von

Delphi-Quellcode:

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.

[Dejan Vu]

Zitat:

Zitat von Blup (Beitrag 1257259)

Fass die z.B. 5000 Dateien zu einer zusammen, die im ersten Schritt importiert wird.

Dann muss man die Dateien aber auch alle einlesen. Und wenn man sie schon mal eingelesen hat, kann man sie auch gleich verarbeiten
Sollte sich eine der Dateien nachträglich ändern, wird die geänderte Version zusätzlich in das Verzeichnis gespeichert.
Wenn sich die Dateien immer mal wieder ändern oder neue hinzukommen, würde ich ein ShellNotify auf das Verzeichnis setzen, dann hat man den zeitlichen Aufwand nur beim ersten Mal. Mit dem ShellNotify muss man aber das Konzept nicht mehr ändern.

[jfheins]

Schau mal, was passiert, wenn du direkt mit ReadFile() aus der WinAPI arbeitest.

Da du ja anscheinend weißt, dass deine Dateien <50KB sind, würde ich einfach mal 50KB Puffer reservieren und die Daten (damit möglichst "auf einmal") lesen. Bei einer SSD auch ruhig mal mit 2 Threads parallel testen ob es schneller ist.

[himitsu]

Zitat:

Zitat von jfheins (Beitrag 1257306)

Schau mal, was passiert, wenn du direkt mit ReadFile() aud der WinAPI arbeitest.

Oder TFileStream, welches auch blos das ReadFile aufruft. :angel:

Wobei auch TStringList alles auf einmal einliest. (stückchenweise ist denen von Emba und eigentlich fast Allen zu aufwändig :roll:)

[Bentissimo]

Ich hatte mal ein halbwegs vergleichbares Problem. Die Aufgabe war, Text-Dateien der Größe 2-4 GB nach Mustern zu durchsuchen. In einem Moment des Denkverzichts hatte ich versucht eine solche Datei mit Notepad zu öffnen. :oops:

Anschließend habe ich stattdessen Edit++ verwendet. Der konnte "ganz locker" damit umgehen. Mit der FastStr-Bibliothek hats dann auch in meinem Programm sehr gut geklappt. Wenn ich mich recht erinnere lagen die Zeiten für das Lesen & Durchsuchen unter 10 Sekunden.

Langer Rede, kurzer Sinn. Ich würde mal versuchen mit Edit++ oder sonst einem vergleichbaren Editor alle Dateien auf einen Rutsch zu öffnen und die Ladezeit (abzüglich einem eventuellen Overhead für den Aufbau der GUI) mit Deinen Zahlen zu vergleichen.

Sollte das Ergebnis besser ausfallen, machen diese Editoren womöglich irgendwas anders als ein "TStringList.LoadFromFile" und ich würde das bereits vorgeschlagene Zusammenfassen der kleinen Dateien zu einer großen ernsthaft in Erwägung ziehen. Auch wenn dann weitere oder andere Herausforderungen auf Dich zukommen.

Möglich, dass ich hier Äpfel mit Birnen vergleiche, aber vielleicht hilft es ja doch irgendwie. :roll:

[Mavarik]

ca. 120 MB? LOL ist doch heute nix mehr...

Blockread direkt ins Ram aller Dateien und dann verarbeiten?

Mavarik