Reguliere expressies zijn ongelooflijk praktisch om input te scannen of tekst manipulaties te doen. Echter, ze staan er ook om bekend langzaam te zijn en dienen dus vermeden te worden indien mogelijk, wordt gezegd.
Dit is een vervolg op PHP optimalisatie: inleiding en PHP arrays
Teksten vinden, opvangen of vervangen
Voor bepaalde zaken zijn zeer goede alternatieven voorhanden en kun je af zonder (in verhouding) langzame oplossingen als reguliere expressies:
- Voor het vervangen van tekst onderdelen op find & replace-basis, kun je str_replace gebruiken;
- Wil je een string opknippen op basis van een specifiek trefwoord of karakter, laat je voorkeur dan uitgaan naar explode, in plaats van preg_split;
- Wil je een deel van een tekst, tot een bepaald karakter in handen krijgen? Zelfs explode kun je dan links laten liggen, ik ben fan van de strstr functie;
- Wil je weten of een tekst een bepaald trefwoord bevat? Gebruik dan alsjeblieft geen reguliere expressies; zelf gebruik ik hiervoor str(i)pos;
- Ook voor bijvoorbeeld afkappen van zogenaamde leading-zero's, zie ik wel eens reguliere expressies gebruikt worden. Ik zeg: trap er niet in, en kijk altijd naar alternatieven. Ze zijn er, heus!
Reguliere expressies toch sneller?
Maar soms heb je geen keuze, zijn reguliere expressies nodig doordat er geen alternatieven zijn. Tot PHP5 en dus de introductie van filter_var, gebruikte ik reguliere expressies om emailadressen te controleren. Frappant om te weten is overigens, dat een reguliere expressie voor dit doeleind, sneller is dan het gebruik van filter_var. Twee maal zo snel in geval van een incorrect emailadres, vier maal zo snel in geval van een correct emailadres. Handig om te weten wanneer je grote databases moet testen. Dit scheelt je 5 seconden per miljoen emailadressen.
Nadelen van reguliere expressies
Wanneer mag je dan wel reguliere expressies gebruiken? Altijd natuurlijk, maar ga na of er alternatieven zijn. Online genoeg discussies te vinden, in het geval van PHP veelal in het voordeel van PHP's DomDocument. Niet onterecht, want je code kan onleesbaarder worden wanneer je gebruik maakt van reguliere expressies. Het is bovendien een meer foutgevoelige methode, je moet bekend zijn met, jawel, reguliere expressies.
Ook kan het gevolgen hebben voor onderhoudbaarheid. Niet alleen voor jezelf, maar ook voor programmeurs die met jouw code aan de haal moeten. Desondanks gebruik maken van reguliere expressies? Documenteer je stappen, of de reguliere expressie goed, voor jezelf en voor andere (PHP) programmeurs.
DomDocument vs reguliere expressies
Toch blijkt in praktijk, dat reguliere expressies sneller zijn. De meeste tijd gaat in het geval van DomDocument zitten in het initialiseren van een instantie. Dit is logisch, want de gehele doorgegeven HTML of XML code, moet als een DOM worden ingelezen, voordat er verdere traversing of manipulaties gedaan kunnen worden.
Omdat we streven naar lage TTFB's ten behoeve van snelle websites voor onze opdrachtgevers, maken we per geval een goede afweging. Wanneer er sprake is van hevige content manipulatie, of wanneer resultaten voor langere periode gecached zullen worden, zullen we altijd kiezen voor DomDocument, doordat het respectievelijk minder foutgevoelig en leesbaarder is.
Wanneer reguliere expressies
Hiermee verklappen we dus dat er situaties zijn dat we kiezen voor reguliere expressies. In ons geval vooral om gepubliceerde emailadressen onleesbaar te maken voor de meeste (spam)bots, om email-spam te voorkomen. Middels reguliere expressies worden deze omgezet, om via JavaScript weer leesbaar te maken voor de reguliere bezoekers. Voordeel is tevens, dat dit qua onderhoud voor de webmasters geen gevolgen heeft.
Ook voor vervangen van placeholders, zoals Wordpress ze ook kent, gebruiken we reguliere expressies. Dit mag echter als logisch worden beschouwd; DomDocument is van nut, wanneer je te maken hebt met MarkUp, zoals HTML of XML.
Voorkeur voor het één (reguliere expressies) hoeft het ander echter niet uit te sluiten. Tegelijkertijd ben ik namelijk groot fan van DomDocument, al dan niet in combinatie met xPath. Dit verdient een eigen artikel, en schrijf ik later over.
