Der schnellste weg Dateien zu parsen?

[Relicted]

sourcen kann ich leider nicht veröffentlichen sonst gibts probleme mit meiner arbeitsstelle )
ich werds mal versuchen anzuwenden und dann mal ne kurze rückmeldungen geben.

Gruß
reli

[Christian Seehase]

Moin Reli,

wie schnell wird denn so eine Datei durchgegangen?

[alzaimar]

Laut SQL-Server Interna (und die sollten es ja wissen), ist ReadFileScatter (Win32-API) das schnellste Verfahren, um Daten zu lesen. Die Buffergröße ist nicht 'ungefähr' 8kb, sondern genau die System-Page-Größe. Alles Weitere in der Hilfe zu o.g. API-Call.

Eigentlich übernimmt die Win-API das Buffern, sodaß ein zweiter Puffer nicht notwendigerweise zu einer Performancesteigerung führt, jedenfalls nicht, soweit ich mich erinnere.

Hier ein Link http://support.microsoft.com/kb/160606/

[negaH]

Danke für diese Info, kannte diese Funktion noch garnicht. Hast du evtl. en Beispiel der Nutzung ?

Gruß Hagen

[Luckie]

Im DF hab eich zwei Beiträge gefunden: [df]ReadFileScatter[/df]. Aber mich würde es für meinen FileSplitter auch interessieren, wie man das implementiert. Ich könnte mir vorstellen, dass das das Splitten beschleunigt, denn da lese ich ja auch die Datei und schreiben sie wieder auf die Festplatte.

[Relicted]

Zitat von Christian Seehase:

Moin Reli,

wie schnell wird denn so eine Datei durchgegangen?

ich denke du meinst die gesammte parse zeit ja?

um eine kleine vorstellung davon zu haben was ich parse ( ich denke nicht vielen wird das dateiformat a2l etwas sagen ) würde ich die
datei mit html quelltext vergleichen. nur etwas umfangreicher und etwas andere syntax


getestet: 9mb datei auf 3000+ Athlon it 1gig ram und ide standard fetplatte in rund 34sekunden

Zitat von alzaimar:

Laut SQL-Server Interna (und die sollten es ja wissen), ist ReadFileScatter (Win32-API) das schnellste Verfahren, um Daten zu lesen. Die Buffergröße ist nicht 'ungefähr' 8kb, sondern genau die System-Page-Größe. Alles Weitere in der Hilfe zu o.g. API-Call.

Eigentlich übernimmt die Win-API das Buffern, sodaß ein zweiter Puffer nicht notwendigerweise zu einer Performancesteigerung führt, jedenfalls nicht, soweit ich mich erinnere.

Hier ein Link http://support.microsoft.com/kb/160606/

ich werde mich ab montag damit mal beschäftigen. wenn ich damit erfolg habe werde ich euch natürlich einen auszug des quelltextes zur verfügung stellen.

[alzaimar]

Unabhängig davon, wie man die Daten denn in den RAM schaufelt, würde ich als optimal schnellen Parser einen DEA implementieren. Aus regulären Ausdrücken kann man so einen DEA (Deterministischen Endlichen Automaten) autmatisch erstellen. Theoretisch würde sich jede Regular-Expressions-Klasse eignen, aber viele der Implementierungen sind im Hauruck-Verfahren erstellt und alles andere als performant.

Ich würde mich vielleicht direkt mit LEX / YACC beschäftigen, die erzeugen die DEA nach dem klassischen Verfahren. Meine Compilerbau-Zeit liegt schon einige Jahre zurück, aber ich würde mal annehmen, das einem DEA performancemäßig kein anderer Algo das Wasser reichen kann.

Über deine Resultate würden sich hier bestimmt Viele freuen!

[Relicted]

hört sich interessant an aber da bin ich ganz ehrlich: never heard about this )

also ich habe jetzt mal nen ca 8kbyte großen buffer eingebaut und die Size, Position mehtoden überschrieben um nicht dauernd nen springenden dateicursor zu haben. durch das verfahren bin ich von
34 auf 7sekunden runter gekommen.

zum thema readfilescatter bin ich leider noch ned zu gekommen da dran rumzutüfteln.. hab leider noch nebenher einige andere aufgaben. aber sobald ich da was habe gibts was zu lesen )


gruß
reli

[alzaimar]

LEX ist ein Programm, das einen Scanner / Tokenizer erzeugt. Du definierst, was die Sprachelemente sind, also Schlüsselwörter, Identifier, Zahlen, terminale Symbole (alle Zeichen, die NICHT Bestandteil eines Wortes sind) usw. Und LEX erzeugt eine Delphi-Unit, das einen Input-Stream in die einzelnen Wörter der Sprache aufteilt und hintereinander die Wörter liefert.

Das dient dann als Input für einen Parser. Der Tokenizer würde z.B. 'begin foobar; end.' in folgende Sequenz übersetzen (1 2 3 4 5). Vorher hast Du ihm gesagt, das das reservierte Schlüsselwort 'begin' den Wert '1' bekommt, ein Identifier den Wert '2', ein Semikolon den Wert '3', das Wort 'end' den Wert '4' und der Punkt den Wert '5'.

Der Input 'begin foobar; blafasel; Begin end; End.' wäre dann '1 2 3 2 3 1 4 3 4 5'.

Anmerkung: LEX erzeugt ursprünglich natürlich C-Code, weil es für UNIX geschrieben wurde. Aber mittlerweile gibt es auch eine gute Implementierung für Delphi. Such mal danach.

Alternativ kannst Du natürlich auch einen 'Frickelparser' basteln, der eventuell doch schneller als ein DEA ist (wenn die Sprache nur wenig reservierte Schlüsselwärter besitzt).

[Relicted]

mein cheffe hat einen parser gebaut. der mann hat ansich auch ahnung von dem was er tut ( so nen dr. titel kommt auch ned von irgendwo )

der parser läuft sehr oop gestützt ab - generell hat jedes token ne eigene klasse die dann wieder wort für wort weiterparsed und dann ggf wieder ne neue klasse created..

die a2l definition hat glaub ich rund 900 seiten

also das ist schon was recht großes ^^