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

Nja, irgendwo war auch ein Test zu sehn, wo InnoDB mindestens doppelt so langsam war.
Außerdem soll InnoDB mehr Speicher belegen. (hab's aber noch nicht getestet)

Mindestens eine Tabelle werde ich vermutlich auch als MEMORY anlegen (mal sehn ob as was ausmacht, ist ja eh nur für 'ne Cache)


Die Volltextsuche werd' ich an ein/zwei Stellen benötigen,
also ich hätte ich mich so oder so je nach Tabelle entschieden.

Also gut, dann mal sehn wie's weitergeht.
Den Kern meines winzigen/kranken CMS hab ich soweit wieder am laufen und alles schön mit Klassen usw.
(Das Einzige, was sich kaum geändert hat, ist meine MySQL-Klasse )

Moin,

ja, InnoDB ist etwas langsamer als MyISAM. Trotzdem rate ich dir dringendst, InnoDB zu verwenden. Warum?

• MyISAM ist nicht transaktionssicher. Da kannst du dir das DBMS gleich sparen.
• InnoDB ist eine relationale Engine, d.h. du kannst Beziehungen zwischen Tabellen herstellen. D.h. du kannst z.B. das Loeschen eines Benutzers verhindern, solange noch Records vorhanden sind die sich auf diesen Benutzer beziehen - und das ohne durch die Datenbank pfluegen zu muessen.
• InnoDB beherrscht Row-Level-Locking. Bei MyISAM muss immer die gesamte Tabelle gesperrt werden, was im Produktivbetrieb richtig viel Aerger machen kann. InnoDB sperrt auf Zeilenebene, d.h. Schreiboperationen werden parallelisiert.
• InnoDB ist zwar etwas langsamer als MyISAM, skaliert aber signifikant besser. Die Verwendung von RAW-Files fuer die Speicherung der Datenbank (d.h. das DBMS geht am Betriebssystem vorbei und schreibt im RAW-Modus auf die Festplatte. Das ist um einen sehr grossen Faktor schneller - mangels Testsystem kann ich dir da grad keine konkreten Zahlen liefern.

Kurzum: wenn du mit Datenbanken arbeiten willst, nimm InnoDB. Wenn du deine Daten irgendwo parken willst um dich in ein paar Jahren darueber zu aergern dass die DB mehr Loecher in den Relationen hat als die Schweiz im Kaese dann verwende InnoDB. Vertrau mir, InnoDB sollte deine Wahl sein.

Greetz
alcaeus

Also kann ich es mir sparen verschiedene Engines zu verwenden?
Brauche ja nicht überall diese schönen Sachen und hätte InnoDB jetzt nur da verwendet, wo ich dieses benötigt hätte.


Ich versuch ja grade diese ForeignKeys verwenden zu wollte ... wenn es denn mal ginge.
(kämpfe grade mit diesem blöden "Can't create table 'test.#sql-ce0_ba' (errno: 150)" und noch keiner der Tipps half. )