Oniguruma Wrapper [noch im Aufbau]

[poker]

So, bin jetzt erst wider zurück und deshalb mein verspäteter Post.

Möglicherweise ist der Benchmark auch einfach komplett falsch, wer Lust hat kann was besseres Beisteuern.

"Ist er auch"[1], was aber weniger an dir liegt als an Oniguruma

Dir ist schon bewusst, das die Optimierung von Oniguruma noch in einer "sehr frühen" Phase ist? Kosako arbeitet an seiner Engine auch gerade erst ca. 4-5 Jahren und Optimierungen hat er erst "kürzlich" vorgenommen (geschätzt vor ca. 1,5 Jahren). Dabei hat er es auch par mal geschafft das einige Optimierungen zu Verschlechterung der Laufzeit geführt haben (Die er aber wider gefixt hat), was IMO normal und Menschlich ist, wenn man berücksichtigt was für ein Monster eine Regexp-Engine eigentlich ist **und** das er **alleine** die Engine entwickelt! Das ist IMO alles bekannt und ich kann daher deine Verwunderung nicht wirklich nachvollziehen.

Ans Herz gelegt, wenn gewünschte, sei dir dieser thread[2]. Ich würde mich da garnicht wunder das selbst im 5.Y.Z-Zweig da noch einiges unentdecktes lauert.

[1][2]: Unter dem Kontext des verlinkten threads kann es durchaus sein, das du ein par Ausdrücke erwischt hast, die für eine nicht beabsichtigte Erhöhung der Laufzeit sorgen; ähnlich wie das Problem mit den zwei Quantoren, das erst ab ca. Oniguruma 4.3.0 auftrat.

und dann müsste man noch ein paar der Funktionen vom Python Layer nach C umlegen (zum Beispiel die sub() Funktion), aber so wie es scheint ist das Performance Problem in Oniguruma selber.

Ich denke nicht das es was zur Verbesserung dre Laufzeit beiträgt Funktionen wie sub in C auszulagern, da bei SRE sehr viel mehr in ``sre_*.py`` ausgelagert ist als z.B. in deinem Wrapper und es dennoch der Performance nicht merklich verschlechtert. Z.B.: Erzeugen ja eine der ``sre_*.py``S einen Kompletten AST in menschen lesbarer Form die dann auch wider auf *.py Seite erst in eine für _sre.c lesbarer Form überführt werden:

Code: Alles auswählen

In [87]: import sre_parse as srep
In [88]: import sre_compile as srec
In [89]: srep.parse(r"\*")
Out[89]: [('literal', 42)]
In [90]: unichr(42)
Out[90]: u'*'
In [91]: srep.parse(r"x|y|z")
Out[91]: [('in', [('literal', 120), ('literal', 121), ('literal', 122)])]
In [92]: srep.parse(r"x|y|zz")
Out[92]: [('branch', (None, [[('literal', 120)], [('literal', 121)], [('literal', 122), ('literal', 122)]]))]
In [93]: p = srep.parse("\*",0)
In [94]: srec._code(p,0)
Out[95]: [17, 8, 3, 1, 1, 1, 1, 42, 0, 19, 42, 1]
In [96]:

Das und vieles mehr macht ja dein Wrapper nicht und daher müsste dein wrapper sogar schneller sein. Daher liegt das Performance Problem an Oniguruma und nicht an deinem Wrapper.

[mitsuhiko]

Den Thread kenn ich Zum Python Zeug: Der Parser in Python ist kein Problem, der Rest läuft in C ab. Aber das Strings in Python zerschneiden kann schon sehr teuer werden. Auf alle Fälle ist ponyguruma für den Moment ziemlich uninteressant weil es einfach zu langsam ist.