problem beim parsen von sehr grossen log-dateien

noch eine frage :), hoffe habt rat ->

ich habe einen parser der log-dateien parst. diese sind aber im schlimmsten fall ca. 300 MB gross.
da der parser ueber ein ifstream den zugriff auf die daten in der datei vornimmt,
ist das parsing doch etwas langsam.

gibt es eine andere vorgehensweise mit der man z.B. die daten (textdatei) vorher in einen speicher zwischenspeichern koennte und von dort das parsing beginnen wuerde ? waere glaube ich etwas schneller als ueber file-deskr. !?!?

kann mich auch irren, falls nicht waere ein tip wie sowas aussehen koennte sehr schoen.

danke.

volkard

pepe75 schrieb:

noch eine frage :), hoffe habt rat ->
ich habe einen parser der log-dateien parst. diese sind aber im schlimmsten fall ca. 300 MB gross.
da der parser ueber ein ifstream den zugriff auf die daten in der datei vornimmt,
ist das parsing doch etwas langsam.
gibt es eine andere vorgehensweise mit der man z.B. die daten (textdatei) vorher in einen speicher zwischenspeichern koennte und von dort das parsing beginnen wuerde ? waere glaube ich etwas schneller als ueber file-deskr. !?!?
kann mich auch irren, falls nicht waere ein tip wie sowas aussehen koennte sehr schoen.
danke.

Diese Art des Vorauslesens auf Verdacht macht das Betriebssystem schon von allein! Auf Windows liest er AFAIR normalerweise die nächsten 2MB auf voraus. Du wirst deshalb mit solchen Tricks nicht schneller. Wenn das Parsen von 300MB mit ifstream deutlich langsamer als das Kopieren von 300MB ist, dann liegsts am Parser.
300MB passen locker in den virtuellen Adressraum, kannst also auch file mapping verwenden. Die reine Lesegeschwindigkeit geht um ein paar mickrige Prozente hoch dadurch. Aber das Handling ist wesentlich(!) einfacher, falls Du auf operator<< verzichten willst alles selber parsen willst. Auf der Suche nach totaler Geschwindigkeit führt daran kein Weg vorbei, aber nicht wegen der leicht erhöhten Lesegeschwindigkeit, sondern wegen der Ranges auf Fremdspeicher statt herkömmlicher besitzender Strings.

Auf der Suche nach totaler Geschwindigkeit führt daran kein Weg vorbei, aber nicht wegen der leicht erhöhten Lesegeschwindigkeit, sondern wegen der Ranges auf Fremdspeicher statt herkömmlicher besitzender Strings

Woran fuehrt kein weg vorbei? am file-mapping?
und was ist ein fremspeicher rang / besitzender string ?

thnx

volkard

pepe75 schrieb:

Woran fuehrt kein weg vorbei? am file-mapping?

Ja.

pepe75 schrieb:

und was ist ein fremspeicher rang / besitzender string ?

Range. Hier ein Zeigerpaar, das Start und Ende eines Dateibereichs kennzeichnet.
Besitzende Strings wie in

std::string zeile;
while(getline(datei,zeile))
   parse(zeile);

müssen ja immer das Zeug kopieren, das nervt auf Dauer. Insbesondere wenn der Parser um ein paar Stufen absteigen muß und dabei den String immer weiter zerlegt.

vielen dank volkard, hat mir sehr geholfen.
gruss