re2 bzw. pyre2 Erfahrungen?

[Herr Lehmann]

Hallo,

ich habe gestern durch Zufall pyre2 entdeckt. Wie man an den Benchmarks sieht soll es wohl bis zu 10 mal schneller sein als das standard re Modul von Python. Da man aber zur installation die Python-Dev Pakete braucht ist es wohl nur bedingt praxistauglich. Ich schreibe gerade an einer Anwendung mit viel regex-Benutzung und deshalb würde ich gerne wissen, ob jemand pyre2 schon produktiv eingesetzt hat bzw ob sich mit cx_freeze auch bin/exe Dateien ohne Probleme bauen lassen wenn man quasi ein custom Python einsetzt. Außerdem wundert mich, dass google zu pyre2 kaum ergebnisse liefert. Auch hier im Forum scheint es noch keine Diskussion darüber zu geben. Woran liegts? Bei den Performancegewinnen sollte das doch eigentlich öfters empfohlen werden?! Oder gibts vielleicht noch eine dritte Alternative die mir nicht bekannt ist und die vl ausgereifter u.o. noch performanter ist?

[BlackJack]

@Herr Lehmann: Was meinst Du mit "custom Python"? Das ist einfach nur ein Modul das in C geschrieben ist. Da wird nichts an Python verändert. Sollte sich also wie jedes andere Modul ausliefern lassen.

[sma]

pyre2 kenne ich nicht, aber ich trolle mal ein bisschen mit der Bemerkung, dass V8 das Potential hat, deutlich schneller als Python zu sein und insbesondere auch seine sehr performante RE-Bibliothek hat. Warum also nicht das nächste Projekte in JavaScript mit Node.js statt Python schreiben... V8 JIT-kompiliert die REs, wie vielleicht Googles RE2 auch. Nach dem Überfliegen der Doku würde ich aber sagen, RE2 gewinnt hauptsächlich seine Geschwindigkeit, indem sie Rückreferenzen wie (a|b)\1 nicht unterstützen.

Stefan

[Leonidas]

Der Mangel an Diskussion liegt wohl daran, dass Pythons ``re`` wohl schnell genug ist. Wenn die Programmperformance ``re`` als Bottleneck hat, dann macht man vermutlich eh irgendwas falsch.

@sma: warum nicht gleich Lua mit LuaJIT? Das hat nicht nur das Potential deutlich schneller zu sein, sondern ist es bereits jetzt. Aber gut, genug getrollt.

[sma]

@sma: warum nicht gleich Lua mit LuaJIT? Das hat nicht nur das Potential deutlich schneller zu sein, sondern ist es bereits jetzt. Aber gut, genug getrollt.

LuaJIT ist in jedem Fall schneller als Python?! So eine ähnliche Bemerkung hat doch neulich eine lange Diskussion über den Sinn und Unsinn von Microbenchmarks (sie sind Unsinn) beschworen. Da wäre ich vorsichtig und daher formulierte ich, dass V8 das Potential hat, schneller als Python zu sein. Und wie es sich im Vergleich zu Lua schlägt, weiß ich leider nicht, hätte aber die Hoffnung, dass die JIT-Technologie gerade bei der RE-Engine auch Lua schlägt. Auf http://shootout.alioth.debian.org/ fehlt für Lua gerade der dna-regexp-Test. Daher kann ich das nicht als Beleg anführen.

Stefan

[Leonidas]

Da wäre ich vorsichtig und daher formulierte ich, dass V8 das Potential hat, schneller als Python zu sein.

Ok, wenn du es aus Angst vor einer weiteren Sinnlos-Diskussion so formulierst, dann ziehe ich natürlich nach und meine auch dass "LuaJIT das Potential hat, schneller als Python zu sein".

Wobei ich ja finde "Potential" ist so ein Wischiwaschiwort ist, wo jedes X das Potential hat schneller als Python zu sein, außer dessen explizit formuliertes Ziel ist es, langsamer als Python zu sein

[Herr Lehmann]

@Herr Lehmann: Was meinst Du mit "custom Python"? Das ist einfach nur ein Modul das in C geschrieben ist. Da wird nichts an Python verändert. Sollte sich also wie jedes andere Modul ausliefern lassen.

Ich meine, dass ich dafür laut doku die Python Development headers brauche und ich habe es jetzt mal versucht zu installieren. Da bekomme ich folgende error:

Code: Alles auswählen

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include/python2.6 -c src/re2.cpp -o build/temp.linux-x86_64-2.6/src/re2.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
src/re2.cpp: In function ‘PyObject* __pyx_f_3re2_7Pattern__search(__pyx_obj_3re2_Pattern*, PyObject*, int, int, re2::RE2::Anchor)’:
src/re2.cpp:5142: error: no matching function for call to ‘re2::RE2::Match(re2::StringPiece&, int&, re2::RE2::Anchor&, re2::StringPiece*&, int)’
/usr/local/include/re2/re2.h:450: note: candidates are: bool re2::RE2::Match(const re2::StringPiece&, int, int, re2::RE2::Anchor, re2::StringPiece*, int) const
src/re2.cpp: In function ‘PyObject* __pyx_f_3re2_7Pattern__finditer(__pyx_obj_3re2_Pattern*, PyObject*, __pyx_opt_args_3re2_7Pattern__finditer*)’:
src/re2.cpp:5788: error: no matching function for call to ‘re2::RE2::Match(re2::StringPiece&, int&, re2::RE2::Anchor, re2::StringPiece*&, int)’
/usr/local/include/re2/re2.h:450: note: candidates are: bool re2::RE2::Match(const re2::StringPiece&, int, int, re2::RE2::Anchor, re2::StringPiece*, int) const
src/re2.cpp: In function ‘PyObject* __pyx_pf_3re2_7Pattern_split(PyObject*, PyObject*, PyObject*)’:
src/re2.cpp:6588: error: no matching function for call to ‘re2::RE2::Match(re2::StringPiece&, int, re2::RE2::Anchor, re2::StringPiece*&, int)’
/usr/local/include/re2/re2.h:450: note: candidates are: bool re2::RE2::Match(const re2::StringPiece&, int, int, re2::RE2::Anchor, re2::StringPiece*, int) const
src/re2.cpp: In function ‘PyObject* __pyx_pf_3re2_7Pattern__subn_callback(PyObject*, PyObject*, PyObject*)’:
src/re2.cpp:8260: error: no matching function for call to ‘re2::RE2::Match(re2::StringPiece&, int&, re2::RE2::Anchor, re2::StringPiece*&, int)’
/usr/local/include/re2/re2.h:450: note: candidates are: bool re2::RE2::Match(const re2::StringPiece&, int, int, re2::RE2::Anchor, re2::StringPiece*, int) const
error: command 'gcc' failed with exit status 1

Zum dem geTrolle hier: Mir ist schon klar das es Sprachen mit besserer re Performance gibt. Aber wenn man gerne mit Python arbeitet und es relativ einfach ist eine bessere Programm Performance zu erzielen warum nicht?

[cofi]

Die Performancevorteil von re2 ist vor allem, dass es keine Spezialfaelle gibt, in denen die Performance auf exponentielle Komplexitaet einbricht.
Lesenswert dazu auch die Serie von Ross Cox dazu:
http://swtch.com/~rsc/regexp/regexp1.html
http://swtch.com/~rsc/regexp/regexp2.html
http://swtch.com/~rsc/regexp/regexp3.html

[BlackJack]

@Herr Lehmann: Da passen wohl Python-Wrapper und re2-Bibliothek nicht zusammen.

[lunar]

@Herr Lehmann: Nun, offenbar ist es eben nicht relativ einfach, „bessere Performance“ zu erzielen. Du scheiterst ja schon am Übersetzen der Bibliothek, und Du bist Python-Entwickler. Ein normaler Benutzer kann C-Erweiterungen erst recht nicht einfach so installieren. Demgegenüber hat die Standardbibliothek eben den unschlagbaren Vorteil, mitgeliefert zu werden.

„Performance“ ist ja auch kein Selbstzweck: Solange das Programm schnell genug ist, besteht eigentlich kein rationaler Grund, die bewährte Standardbibliothek durch ein neues, unbekanntes Modul zu ersetzen.

Es ist ja auch nicht so, als käme der Performance-Vorteil umsonst. Der Preis für den effizienteren Algorithmus ist der Verzicht auf nicht unbedingt essentielle, aber manchmal ungeheuer praktische Konstrukte wie Rückreferenzen. Diese Beschränkung ist auch nicht durch die Implementierung bedingt, sondern eine inhärente Eigenschaft des verwendeten Algorithmus.

Anders gesagt, reguläre Ausdrücke, so wie sie von "re" verstanden werden, lassen sich nicht effizienter implementieren. Mithin ist "re2" auch kein Ersatz für "re", sondern nur eine unter bestimmten Umständen eine Alternative (e.g. bei echten, also gemessenen Performance-Problemen, und wenn man auf diverse Konstrukte verzichten kann).