TPerlRegEx - stack overflow

[Namenloser]

@WladiD:
Ein auf eine geöffnete Klammer folgendes Fragezeichen markiert den Beginn eines Subpatterns und ist gültige PCRE-Syntax. Die geschweiften Klammern sollte man allerdings besser escapen.

Abgesehen davon sollte ein selbstgeschriebener Parser eigentlich immer schneller sein als Regex, zumindest in einer kompilierenden Sprache wie Delphi.

@liftoff:
Hatte ich mit Greedy/Non-Greedy wohl doch den richtigen Riecher

Geht der String denn nach dem -} noch weiter? Denn die Sub-Expression [^\r\n]*\r\n matcht ja auch auf Anfang und Ende eines solchen Konstrukts, d.h. die Engine geht immer erst mal bis zum Ende des Strings, weil ja immer noch ein -} folgen könnte; erst am Ende merkt sie dann, dass dort keines ist, und geht schrittweise zurück. Das könnte also, gerade in Kombination mit Sub-Patterns, die vielleicht rekursiv implementiert sind, die Ursache für den Überlauf sein.

[liftoff]

Ja, gutes Näschen.

Es folgt am Anfang der letzten Zeile immer ein '-}'

Eine Swiftnachricht besteht aus mehreren Blöcken.

Code:

{1:...}{2:...}{3:...}{4:
Nachrichteinhalt
-}{5:}

Der Block 4 (Textblock) muss immer mit '{4:'+Zeilenumbruch anfangen und mit Zeilenumbruch+'-}' enden.

Blöcke 1+2 enthalten Adressinformationen (Absender+Empfänger), 3 Userinfos und 5 Checksummen und son Zeuchs. 1+3+5 sind optional.

Ich habe eben auch noch einen anderen funktionierenden Konstrukt gebastelt

Code:

{4:\R(?:[[:ascii:]]+\R)+-}

[liftoff]

So. Nach einigen Tests habe ich mich für die non-greedy Variante entschieden.
Performance liegt bei etwa 22000 Nachrichten/h, also parsen, zerlegen und strukturiert in der DB ablegen.
Auf den produktiven Systeme geht das noch ne ganze Ecke flotter.
Ist zwar langsamer als vorher, jedoch vollkommen zufriedenstellend.
Nun lass ich die Bibliothek auf die anderen Prozesse los.

Dank Euch bis hierhin für die Hilfe.

@ele
Bin sehr zufrieden mit meinem Arbeitgeber. Aber vielleicht kann man sich ja auf fachlicher Ebene ein wenig austauschen.
Bei mir steht beispielweise demnächst die Erweiterung auf ISO20022 (XML) an.