Oniguruma Wrapper [noch im Aufbau]

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Beitragvon poker » Donnerstag 4. Oktober 2007, 20:31

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

blackbird hat geschrieben: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.


blackbird hat geschrieben: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:
poker hat geschrieben:

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.
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Freitag 5. Oktober 2007, 22:31

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.
TUFKAB – the user formerly known as blackbird

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder