Textparser - wie und womit?

Computer: Software & Programmierung Programmierung allgemein
#1

Moin,

da ich mich auf Windows am besten mit VB und VBA auskenne, habe ich auch Textparser bisher damit geschrieben, vor allem mit Excel-VBA, weil ich die Pfade zu den Quelldateien aus den Tabellen rausziehen und die Ergebnisse dann auch gleich in Tabellen schreiben kann.

Verwendung fanden hauptsächlich Funktionen wie Mid(), Left(), Right() und InStr(). Also Basis-Text-Funktionen. Nrmalerweise lese ich Zeile für Zeile ein und suche nach Erkennungsmarken oder bestimmten Konstrukten.

Ich könnte mir nun vorstellen, dass es z.B. mit C oder C++ ein wenig schneller ginge als mit VBA. Da ich mich mit C aber fast gar nicht auskenne bisher, habe ich es noch nicht probiert.

Frage 1: Wäre C wirklich schneller? Oder nimmt sich das bei solchen Funktionen nichts?

Frage 2: Wäre ein anderer Compiler als C auch geeignet?

Frage 3: Welche Verfahren sind am schnellsten? Die oben genannten Text-Funktionen oder z.B. auf regulären Ausdrücken basierte?

Frage 4: Wenn ich jetzt mal C nehme - würde es Sinn machen, ein entsprechendes AddIn in C zu schreiben und das dann in VB(A) einzubinden? Oder bremst VB das dann irgendwie aus? Kann ich mir eigentlich nicht vorstellen.

Danke für Hinweise,
Kristian

#2

Hi!

Moin,

[…]

Frage 1: Wäre C wirklich schneller? Oder nimmt sich das bei
solchen Funktionen nichts?

Es kommt zwar auf die Art der Programmierung an, aber in aller Regel kann man mit C/C++ schon schnelleren Code als mit VBA erzeugen.

Frage 2: Wäre ein anderer Compiler als C auch geeignet?

Na klar. Zeichenkettenoperationen, wie Du sie offenbar machst, sind in jeder vernünftigen Programmiersprache möglich.

Frage 3: Welche Verfahren sind am schnellsten? Die oben
genannten Text-Funktionen oder z.B. auf regulären Ausdrücken
basierte?

Auch da hängt es hochgradig von der Implementierung ab.
Der Vorteil von reg. Ausdrücken ist zwar i.d.R. nicht die besonders schnelle Ausführung (wenngleich man auch z.B. durch Vorcompilieren des Ausdrucks dieses beeinflussen kann), sondern die flexible und kompakte Formulierung der Muster.
Man kann davon ausgehen, dass ein regulärer Ausdruck auch das richtige Ergebnis liefert. Wenn Du das Parsing selber programmierst, ist das zwangsläufig immer anfällig für Bugs…

Frage 4: Wenn ich jetzt mal C nehme - würde es Sinn machen,
ein entsprechendes AddIn in C zu schreiben und das dann in
VB(A) einzubinden? Oder bremst VB das dann irgendwie aus? Kann
ich mir eigentlich nicht vorstellen.

Würde vermutlich schon Sinn machen. Das (zeit-)aufwändige bei solchen Aufrufen ist meistens der Aufruf selbst. Wenn die Funktion im AddIn nur wenig macht, dafür aber x-tausend mal aufgerufen wird, dann ist der Overhead vermutlich zu groß. Darum also für die beste Performance so implementieren, dass irgendwelche engen Schleifen ausschließlich IM AddIn laufen und erst am Schluß das kompakte Ergebnis zurückgegeben wird.

Danke für Hinweise,
Kristian

Gruß,
Martin

#3

C/C++ ist potentiell wesentlich schneller.
es gibt die (windows) GNU Pakete
flex zur lexikalischen Analyse,
-kommen bestimmte Worte oder Textmuster (reguläre Ausdrücke) im Text vor und was steht dahinter, bis ein neues gesuchtes Muster kommt-

und Bison zur grammatikalischen Analyse
-sind diese dann in der richtigen Reihenfolge und Hirarchie,sodass
das und das dahintestehende in Excel eingeladen werden kann-

Die beiden Tools erzeugen C Code, den man innerhalb
einer DLL auch von VB/VBA ansprecehn kann, in C/C++
sowieso.

Die Grammatik muss sich aber als BNF darstellen lassen,
natürliche Sprachen lassen sich damit nicht analysieren,

Auf jeden Fall ist es ein Kinderspiel damit, zu parsen.
Der erzeugte C Code ist hocheffizient und konsistent,
verfolgt dann aber die vorgegebene Logik bis ins letzte,
so dass es zum Stapelüberlauf kommen kann.
Man kann ihn aber abändern.

Etwas knifflig ist die Fehlerbehandlung, wenn man mehr will als nur einen Abbruch des Lexers oder Parsers.

Man könnte flex und bison dazu bringen VB/VBA
code zu erzeugen anstatt C, vielleicht gibt es das schon,
für Java gibt es das.
Das würde aber nicht die regulären Ausdrücke (Regex) umfassen,
Da ist Microsoft sehr spät aufgesprungen, auf den Zug.
Beim .NET Kram ist es aber dabei, wenn auch nicht kompatibel zum
Berkley Regex, Regex in .NET ist aber ähnlich leistungsfähig.

Sind die zu analysierenden Daten aber nicht unendlich hirarschisch
gegliedert, befindet sich eine Informationseinheit also auf einer Zeile, ermöglicht sich die Benutzung von perl oder awk
auch sehr schnell, auch Gnu für Windows).
Ist es XML kann man auch xmlgawk nehmen oder perl mit expat.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo!

Ich musste auch mal einen Textparser in VB schreiben, das ganze war sehr langsam.

Viel besser geht das in C/C++, aber auch hier muss man aufpassen:
Es ist gar nicht gut mit Funktionen wie Mid,Left usw. der CString Klasse zu arbeiten, weil hier jede Menge Konstruktor/Destruktoraufrufe die Performance vernichten.

Anstatt mit Mid usw. zu Arbeiten habe ich mir immer start- und endPosition im String gemerkt, und so unnötige Speicherkopierereien vermieden.

Du kannst auch „Generate Intrinsic Functions“ bei den Compileroptions einschalten, dann werden strcmp & co durch die Inline versionen ersetzt…

Wenns um Geschwindigkeit geht, kann ich dir generell nur empfehlen die Finger von VB zu lassen und C/C++ zu verwenden.

Gruß Pauli!