PHP ereg vs preg

Question

Ich habe festgestellt, in der PHP Regex-Bibliothek gibt es eine Wahl zwischen ereg und preg. Was ist der Unterschied? Ist einer schneller als der andere und wenn ja, warum ist der langsamere nicht veraltet?

Gibt es Situationen, in denen es besser ist, eine über der anderen zu verwenden?

Answer 1

php.net/ereg Besuch zeigt Folgendes:

Warnung

Diese Funktion wie PHP 5.3.0 und ENTFERNT ab PHP 6.0.0 nicht mehr unterstützt. Von dieser Funktion wird dringend abgeraten.

unten auf der Seite nur ein bisschen weiter und wir dies lesen:

Hinweis: preg_match(), die eine zu Perl kompatible Syntax regulärer Ausdrücke verwendet, ist häufig die schnellere Alternative zu ereg() .

Beachten Sie meine Betonung.

Answer 2

Preg ist die Perl Compatible Regex Bibliothek
ereg die complient regex Bibliothek POSIX ist

Sie haben eine etwas diffrent Syntax und Preg ist in einigen Fällen etwas schneller. ereg ist veraltet (und es wird in php6 entfernt), daher würde ich nicht empfehlen, es zu verwenden.

Answer 3

Nun, ereg und seine Derivate-Funktionen (ereg_match, etc) sind in php5 veraltet und in php6 entfernt, so dass Sie wahrscheinlich am besten mit der Preg-Familie gehen.

preg ist für reguläre Ausdrücke im Perl-Stil, während ereg Standard POSIX regex ist.

Answer 4

Es gibt viele Diskussionen darüber, was schneller und besser ist.

Wenn Sie vorhaben, irgendwann nach PHP6 zu wechseln, wird Ihre Entscheidung getroffen. Ansonsten:

Der allgemeine Konsens ist, dass PCRE die bessere Allround-Lösung ist, aber wenn Sie eine bestimmte Seite mit viel Verkehr haben, und Sie PHP6 nicht benötigen, kann es einige Tests wert sein. Zum Beispiel von den PHP-Handbuch Kommentare:

Deprecating POSIX Regex in PHP für Suche Perl ist Holzplatten und Ziegel für ein Haus mit vorgefertigten Räume und Wände wie zu ersetzen. Sicher, Sie können in der Lage sein zu mischen und Spiel einige der Teile, aber es ist viel einfacher zu ändern mit allen Stücken vor Ihnen ausgebreitet.

PCRE schneller als POSIX RE? Nicht immer. In einem aktuellen Suchmaschinen-Projekt hier bei Cynergi, hatte ich eine einfache Schleife mit einer einige nette ereg_replace() Funktionen, die dauerte 3min, um Daten zu verarbeiten.Ich änderte diese 10-Linien-Schleife in eine 100-Linie handgeschriebenen Code für den Ersatz und die Schleife dauerte jetzt 10s, um die gleichen Daten zu verarbeiten! Dies öffnete mein Auge, was kann IN EINIGEN FÄLLEN sehr langsam sein regulären Ausdrücken. Kürzlich entschied ich in Perl-kompatiblen regulären Ausdrücke (PCRE) zu suchen. Die meisten Seiten beanspruchen PCRE sind schneller als POSIX, aber ein paar behaupten anders. Ich entschied mich für Bechmarks meiner eigenen. Meine ersten paar Tests PCRE bestätigt schneller, aber ... die Ergebnisse waren etwas anders als andere waren immer, so entschied ich mich jeden Fall von RE Nutzung Benchmark ich auf einer 8000-line sichern hatte (und schnell) Webmail-Projekt hier bei Cynergi, um es auszuprobieren. Die Ergebnisse? Nicht zutreffend! Manchmal PCRE sind schneller (manchmal um einen Faktor größer als 100x schneller!), Aber einige andere mal POSIX RE sind schneller (um einen Faktor von 2x). Ich muss immer noch eine Regel auf finden, wenn der eine oder andere schneller ist. Es ist nicht nur um die Suche Datengröße, Datenmenge angepasst oder „ Kompilierung RE“, die würde zeigen, wenn Sie die Funktion oft wiederholt: würde man immer schneller sein als die andere. Aber ich habe hier kein Muster gefunden. Aber die Wahrheit ist gesagt, ich habe auch nicht nehmen Sie sich die Zeit, in die Quelle Code zu suchen und das Problem zu analysieren. Ich kann Ihnen einige Beispiele geben, obwohl. Die POSIX RE ([0-9] {4})/([0-9] {2})/([0-9] {2}) [^ 0-9] + ([0-9 ] {2}): ([0-9] {2}): ([0-9] {2}) ist 30% schneller in POSIX als wenn in PCRE konvertiert wurde (auch wenn Sie \ d und \ verwenden) D und nicht-gieriges Matching). Auf auf der anderen Seite, eine ähnliche PCRE komplexes Muster/[0-9] {1,2} [ \ t] + [a-zA-Z] {3} [\ t] + [0-9] { 4} [ \ t] + [0-9] {1,2}: [0-9] {1,2} (: [0-9] {1,2})? [ \ t] + [ + -] [0-9] {4}/ist in PCRE 2,5x schneller als in POSIX RE. Einfache Ersatzmuster wie ereg_replace ("[^ a-zA-Z0-9 -] +", "", $ m ); sind in POSIX RE 2x schneller als PCRE. Und dann werden wir wieder verwirrt , weil ein POSIX RE-Muster wie (^ | \ n | \ r) begin-base64 [\ t] + [0-7] {3,4} [ \ t] + ... ... ist 2x schneller als POSIX RE, aber die Groß-/Kleinschreibung wird nicht beachtet PCRE /^ Empfangen [\ t] *: [\ t] von [\ t] + ([^ \ t] +) [\ t ]/i ist 30x schneller als die POSIX RE Version! Wenn es um die Groß-/Kleinschreibung geht, hat PCRE bisher als die beste Option angesehen. Aber ich fand einige wirklich seltsames Verhalten von ereg/eregi. Auf einer sehr einfachen POSIX RE (^ | \ r | \ n) MIME-Version [\ t]: fand ich eregi() unter 3.60s (nur eine Nummer in einem Test-Benchmark), während die entsprechende PCRE nahm 0,16s! Aber wenn ich ereg() (Groß-und Kleinschreibung) die POSIX RE Zeit ging auf 0,08 s! So habe ich weiter untersucht. Ich habe versucht, die POSIX RE ohne Berücksichtigung der Groß-/Kleinschreibung zu machen. Ich habe so weit: (^ | \ r | \ n) [mM] [i] [mM] [eE] -vers [iI] [oO] [nN] [ \ t] *: Diese Version nahm auch 0,08s. Aber wenn ich versuche, die gleiche Regel auf einer der Buchstaben 'v', 'e', ​​'r' oder 's' Buchstaben, die nicht geändert werden, ist die Zeit zurück auf die 3,60s Marke, und nicht allmählich, aber sofort so! Die Testdaten hatten keine "Vers" in es, andere "Mime" -Wörter drin oder irgendeine "ion", die den POSIX-Parser verwirren könnte, so bin ich ratlos. Bottom Zeile: immer Benchmark Ihre PCRE/ POSIX RE, um den schnellsten zu finden! Tests wurden mit PHP 5.1.2 unter Windows von der Befehlszeile durchgeführt. Pedro Freire cynergi.com

Answer 5

Obwohl ereg in PHP 5.3 veraltet ist, sind die mb_ereg * -Funktionen nicht. Ich glaube, der Hauptgrund dafür ist, dass PHP6 alle MB/Unicode-Unterstützung wiederherstellt und daher die alten "regulären" ereg-Methoden nutzlos sind, da die mb_ereg neuer/besser sein wird.

Ich weiß, dass es die Frage bezüglich der Geschwindigkeit nicht beantwortet, aber es erlaubt Ihnen, weiterhin POSIX und PCRE zu verwenden.