Die sind auch nicht böse, nur verhältnismäßig langsam.
Das kommt immer auf den Anwendungsfall an.

Nja, weil sich doch "beschwert" wurde, daß ich ein paar davon verwendete.
(wobei sie nichtmal oft aufgerufen wurden)

Boah. Wahnsinn. Himi, sorry, aber manchmal frag ich mich echt ob dir zu helfen ist.

RegExen sind langsam. Das gilt fuer jede Art davon. Ich zeig dir mal einen Performance-Test:

zusammenfalten · markieren

PHP-Quellcode:

$preg = '#Foobar#i';
$toMatch = 'Foobar';

$sample = 'Foobar';

$num = 100000;

$pregStart = microtime(true);
$i = 0;
while ($i < $num) {
   preg_match($preg, $sample);
   $i++;
}
$pregStop = microtime(true);

$eqStart = microtime(true);
$i = 0;
while ($i < $num) {
   ($sample == $toMatch);
   $i++;
}
$eqStop = microtime(true);

echo 'Time preg: '. ($pregStop-$pregStart) .' seconds<br />';
echo 'Time eq: '. ($eqStop-$eqStart) .' seconds<br />';

Die Ausgabe bei mir:

Zitat:

Time preg: 0.75503706932068 seconds
Time eq: 0.045335054397583 seconds

Soll heissen: vermeide preg wenn es nicht sein muss. Wenn benoetigt wird dann gibts keinen Weg drumrum. Ich habe einen Fall wo ich eine URL der Form <md5>.png in latex.php?id=<md5> umwandeln muss. Das geht nicht ohne mod_rewrite. Wenn ich es jetzt aber verwende um eine saubere URL-Struktur reinzubringen, bin ich echt selber Schuld (also sowas wie /forum/Foo-Bar/topic/Blabla/50 zu viewtopic.php?t=50 umzuschreiben) und verdien nichts besseres als eine sacklangsame Applikation.

Aber, wenn du auf solchen Sachen rumreiten willst, bitte. Du hast nach einer Meinung gefragt und sie gekriegt. Du musst halt damit leben dass sie nicht unbedingt das ist, was du dir erhofft hast.

Greetz
alcaeus

Dein Vergleich hinkt aber etwas.

Wenn man das preg_match nutzt, um etwas zu suchen, dann kann man es doch nicht mit einem einfachen Vergleich (=) vergleichen?

strpos oder so wäre da wohl ein besserer Vergleichspartner.

markieren

Code:

$preg = '#Foobar#i';
$pos = 'Foobar';
$toMatch = ' Foobar ';

$num = 100000;

$pregStart = microtime(true);
$i = 0;
while ($i < $num) {
    preg_match($preg, $toMatch);
    $i++;
}
$pregStop = microtime(true);

$eqStart = microtime(true);
$i = 0;
while ($i < $num) {
    strpos($toMatch, $pos);
    $i++;
}
$eqStop = microtime(true);

echo 'Time preg: '. ($pregStop-$pregStart) .' seconds<br />';
echo 'Time pos: '. ($eqStop-$eqStart) .' seconds<br />';

Time preg: 0.090588092803955 seconds
Time pos: 0.047449111938477 seconds

Gut, hier ist es zwar immernoch knapp doppelt so langsam ... ~2:1,
aber das 17:1 kann ich so nicht bestätigen.


Aber mal ganz im Ernst, fallen die 0.5 Microsekunden mehr pro Vergleich, bei den wenigen Vergleichen und vorallem für soein kleines Projekt, wirklich noch auf?
Bei z.b. 20 Vergleichen (ich hatte viel weniger drin) macht das hier grade mal 10 Microsekunden aus, was durch die "langsame" Internetverbindung allemale überboten wird.

Mit einem etwas längerem Text vor dem Gesuchten, kam ich maximal auf die 4-fache Zeit. (also in dem Größenbereich/Länge, welchen ich erwarten würde)



Ich spare auch gerne hier und da mal 'nen bissl Zeit ein, aber hier (vorallem in meinem Fall) fällt es schlußendlich garnicht auf.

Hi,

Zitat von himitsu:

Wenn RegExen doch sooooo böse sind und möglichst vermieden werden sollen,
dann darf man auch keine RewriteEngine verwenden, denn dieses Ding ist ja bis zum Rand damit vollgestopft.

im Prinzip hast du da auch Recht. Apache kann diese Regexen aber ganz toll (im kompillierten Zustand) zwischenspeichern. Bin mir im Moment auch gar nicht sicher, ob PHP das nicht auch irgendwie kann (sowas wie preg_compile?). Ich mag mod_rewrite auch nicht so besonders. Meine Applikationen bau ich auf, indem ich einfach alle URLs auf die index.php weiterleite - sofern die aufgerufene URL nicht als Datei wirklich existiert. (sinnvoll für statische Daten wie Bilder oder CSS)

Liebe Grüße,
Valle

Also ich hatte mit himitsu's Code so Mittel ca. (PHP 5.2 und PHP 5.3):

markieren

Code:

Time preg: 0.11731195449829 seconds
Time pos: 0.036504030227661 seconds

Dennoch würde ich sagen, dass es in vielen Fällen eine Fallentscheidung ist, ob reguläre Ausdrücke eingesetzt werden sollten oder nicht.
Bei seltenen Tasks kann man sie auf jeden Fall einsetzen. Bei Scripten, die ggf. häufig aufgerufen werden könnten, würde ich auf ausgiebigere Last-Tests ansetzen. Damit kann man ermitteln, ob eventuelle Bottlenecks wirklich am RegEx liegen oder nicht vielleicht doch an anderen Code-Stellen (DB-Zugriff, SQL-Statements, Design im allgemeinen...). Je nach Komplexität der Überprüfung, ist ein RegEx vielleicht sogar besser - wenn z.B. ein String sonst erst komplett zerbröselt werden müsste...

Edit: Bei meinem PHP Inspection Unit (siehe Signatur) Projekt wird ein PHP-Quelltext auch über reguläre Ausdrücke analysiert und im Endeffekt ist die Performance auch noch recht praktikabel (750 KB Quelltext in < 1 Sekunde) - ohne reguläre Ausdrücke wäre der Code viel länger und komplizierter (und somit schwieriger zu warten) geworden.

*seufz* Leute, es geht hier nicht um gut oder schlecht. Man sollte sich aber ueberlegen, ob man wirklich Regular Expressions einsetzen muss.

@himitsu: dein Vergleich hinkt genauso - mein Beispiel berief sich auf genau den Fall den ich (entweder in diesem Thema oder in einem anderen "Helft mir mit PHP"-Thema) beschrieben hatte.

Im konkreten Fall mussten fuer ein Ticketing-System das Support-Emails annimmt Blacklist-Eintraege geprueft werden. Die Blacklist kann auch Regex, weshalb auch vollstaendige E-Mail-Adressen als RegEx der Form "^foo@bar\.com$" gespeichert wurden. Dass das ein Performance-Loch (und das meine ich woertlich) sein kann, wurde damals gar nicht bedacht. Selbst wenn man dein Beispiel mit strpos nimmt, ein Faktor von zwei ist immer noch ein Faktor von zwei.

Was ich sagen will ist: pruef ob du etwas evtl. ohne preg machen kannst. Code wie z.B. return !preg_match('#^(\.|\.\.|\.htaccess|index\.htm(l)?)$#i', $FileName); ist naemlich absolut sinnbefreit und ausserdem schlecht testbar.

Greetz
alcaeus

PS da ich waehrend der preg-Untersuchung darauf gestossen bin:
$MailMask = '#^[\w.+-]{1,64}\@[\w.-]{1,255}\.[a-z]{2,6}$#'; Ich empfehle eine Lektuere von RFC 5322 und RFC 5321. Angenommen meine Mail-Adresse ist foo.bar|foobar@meinmailprovider.de. Willst du mir sagen dass ich keine Post von dir kriegen darf?
Kleiner Tipp an alle: wenn ihr schon ne Regular Expression schreibt, die E-Mail-Adressen validieren soll, dann macht euch bitte schlau wie eine Mail-Adresse aufgebaut ist. Auch der Hostname-Part der Validierung ist leider falsch.

Ja, ich hab auch irgendwo eine angeblich "komplette" RFC-irgendwas kompatible RegEx für eMails rumliegen, aber das Monstrum wollte ich nicht einbauen.
War auch geplant da mal eine bessere Methode zu verwenden, aber zum Testen reichte mir dieser "einfache" Vergleich.



Da es grade da drüben um Foreign Keys geht und MySQL dieses ja kennt.
Damit könnte man ja so Einiges vereinfachen.

MyISAM kennt zwar die Syntax, jedoch ignoriert es dann alles.
InnoDB soll es können, aber dieses soll ja langsamer sein.

Was empfiehlst du nun da?
- langsamere Engine (bei den Tabellen, wo sowas verwendet wird)
- oder keine Foreign Keys verwenden und selber Code gegenprüfen, aufräumen usw.

Zitat von himitsu:

MyISAM kennt zwar die Syntax, jedoch ignoriert es dann alles.
InnoDB soll es ja können, aber dieses soll langsamer sein.

Was empfiehlst du nun da?
- langsamere Engine (bei den Tabellen, wo sowas verwendet wird)
- oder keine Foreign Keys verwenden und selber Code gegenprüfen, aufräumen usw.

Wo hast du denn das her? Okay, einmal googlen reicht
InnoDB ist meines Wissens nach neuer und mind. genauso schnell. Meine Faustregel war bisher: Immer InnoDB benutzen es sei denn, man braucht unbedingt die Volltextsuche von MyISAM.
Ist aber trotzdem nicht verkehrt. InnoDB bringt einfach viele Features mit, die inzwischen Standard sein sollten. Transaktionen z.B.

Hi!

Ich bin der Meinung, man sollte FKs nutzen, wo man kann.
Daher würde ich zu InnoDB raten.


Grüße, Frederic