[php] Vraag mbt explode en preg_match *

[troxx]

Beste Tweakers.
Op deze eenzame avond (nacht inmiddels) ben ik maar weer is met een oud projectje begonnen. Ik heb een vraag. Inmiddels werkt mijn kort stukje code wel, maar ik heb het idee dat ik erg veel onnodige load genereer.

Het is de bedoeling dat variabele $test (dit is een voorbeeld, zo komt die normaal uit de db) wordt geconverteerd in een array met de waarde die gelijk is aan het getal tussen de || ||. Ik heb preg match al gebruikt maar heb het idee dat dat nog veel langer duurde.

Mijn code is nu:

PHP:

<?
$test = "||1|| ||8|| ||14|| ||23||";
$testje = explode(" " ,$test);

foreach ($testje as $test) {
    $testa = explode("||", $test);
}
?>

De hierbij behorende (print_r) output is:

code:

Array
(
    [0] => 
    [1] => 1
    [2] => 
)
Array
(
    [0] => 
    [1] => 8
    [2] => 
)
Array
(
    [0] => 
    [1] => 14
    [2] => 
)
Array
(
    [0] => 
    [1] => 23
    [2] => 
)

In principe werkt het dus, wie heeft er suggesties voor snellere code?

[Pelle]

De enige manier om te testen of jouw manier sneller is dan een preg_match_all is door een loopje te schrijven dat 1000 keer jouw code en 1000 keer de preg_match_all uitvoert. Ff timen, en je weet wat het snelste is

[crisp]

PHP:

<?php

$test = '||1|| ||8|| ||14|| ||23||';
preg_match_all('/\|\|(\d+)\|\|/', $test, $matches);

echo '<pre>';
echo print_r($matches[1]);
echo '</pre>';

?>

geeft

code:

Array
(
    [0] => 1
    [1] => 8
    [2] => 14
    [3] => 23
)

en lijkt me in dit geval het makkelijkst. Of het sneller is weet ik niet...

[stekkel]

Dit zou ook moeten werken en is denk ik sneller.

PHP:

$test = '||1|| ||8|| ||14|| ||23||'; 
$test = substr(str_replace('| |','',$test),2,-2);
$array = explode('||',$test);

Probeer zelf maar uit of het echt sneller is.

[ Voor 30% gewijzigd door stekkel op 01-08-2003 02:22 ]

[sjokki]

PHP:

<?php
if (preg_match_all('/\d+/', $test, $matches))
{
  print_r($matches);
}
?>

Er van uit gaande dat er geen andere dingen in de string staan.

edit:

De code van stekkel is een sneller dan die van mij:
0.00213599205017 stekkel
0.00340092182159 sjokki
0.00469899177551 crisp

Hoewel dit soort metingen ook verschillen per computer.

[ Voor 89% gewijzigd door sjokki op 01-08-2003 05:42 ]

[stekkel]

sjokki schreef op 01 August 2003 @ 05:19:

PHP:

<?php
if (preg_match_all('/\d+/', $test, $matches))
{
  print_r($matches);
}
?>

Er van uit gaande dat er geen andere dingen in de string staan.

edit:

De code van stekkel is een sneller dan die van mij:
0.00213599205017 stekkel
0.00340092182159 sjokki
0.00469899177551 crisp

Hoewel dit soort metingen ook verschillen per computer.

Bedankt voor de test

Wist niet dat het zoveel scheelde (40%) maar weet wel dat je niet preg_match_all moet gebruiken wanneer je het zelfde kan bereiken met hele snelle php functies als str_replace en explode.

(als snelheid er toe doet)

[ Voor 5% gewijzigd door stekkel op 01-08-2003 18:53 ]

[mocean]

stekkel schreef op 01 augustus 2003 @ 01:46:
Dit zou ook moeten werken en is denk ik sneller.

PHP:

$test = '||1|| ||8|| ||14|| ||23||'; 
$test = substr(str_replace('| |','',$test),2,-2);
$array = explode('||',$test);

Probeer zelf maar uit of het echt sneller is.

Nog sneller? (geen str_replace meer)

PHP:

$test = '||1|| ||8|| ||14|| ||23||'; 
$test = substr($test,2,-2);
$array = explode('|| ||',$test);

[stekkel]

mocean schreef op 01 August 2003 @ 19:02:
[...]


Nog sneller? (geen str_replace meer)

PHP:

$test = '||1|| ||8|| ||14|| ||23||'; 
$test = substr($test,2,-2);
$array = explode('|| ||',$test);

voor stekkel

[MBV]

Mensen, waar gaat het om? Als je dit soort verschillen (40% blijft maar 2 miliseconden verschil) gaat uitpluizen, kan je dan niet beter je website gaan verbeteren, navigatie etc, zodat hij sneller werkt? Of gaat het om meer dan 212 ( 1/0.00469899177551 = 212) bezoekers per minuut?
Dat soort theoretische vragen is meestal zinloos, ga liever die tijd besteden aan betere programma's!

[Verwijderd]

MBV schreef op 02 August 2003 @ 00:08:
Mensen, waar gaat het om? Als je dit soort verschillen (40% blijft maar 2 miliseconden verschil) gaat uitpluizen, kan je dan niet beter je website gaan verbeteren, navigatie etc, zodat hij sneller werkt? Of gaat het om meer dan 212 ( 1/0.00469899177551 = 212) bezoekers per minuut?
Dat soort theoretische vragen is meestal zinloos, ga liever die tijd besteden aan betere programma's!

Hij zegt dat die het uit een db haalt, misschien moet dit truukje wel een stuk of 50 keer draaien in 1 php file. Dan gaat het opeens over 1 of 2 tienden. Dan moet er ook nog meer gedaan worden met de data waarschijnlijk. Kortom het kan dus best wel wat schelen uiteindelijk.

[stekkel]

Verwijderd schreef op 02 August 2003 @ 00:16:
[...]

Hij zegt dat die het uit een db haalt, misschien moet dit truukje wel een stuk of 50 keer draaien in 1 php file. Dan gaat het opeens over 1 of 2 tienden. Dan moet er ook nog meer gedaan worden met de data waarschijnlijk. Kortom het kan dus best wel wat schelen uiteindelijk.

Precies !!!

MBV schreef op 02 August 2003 @ 00:08:
Mensen, waar gaat het om? Als je dit soort verschillen (40% blijft maar 2 miliseconden verschil) gaat uitpluizen, kan je dan niet beter je website gaan verbeteren, navigatie etc, zodat hij sneller werkt? Of gaat het om meer dan 212 ( 1/0.00469899177551 = 212) bezoekers per minuut?
Dat soort theoretische vragen is meestal zinloos, ga liever die tijd besteden aan betere programma's!

De gedachte dat performance niet uit maakt is bullshit.

Zelf heb ik te maken met imap servers die geen server side sort ondersteunen. Dat betekent dat wanneer je een berichtenlijst wilt zien die gesorteerd is en de betreffende mailbox heeft 2000 mailtjes het NOGAL wat uitmaakt als je een beetje oplet wat voor routines je gebruikt.

Bovendien, als je bij voorbaat al weet dat het ene sneller is dan het ander, waarom zou je dan het trage prefereren ????

Als je niet beter weet, oke, dan kan ik me het voorsteller, maar als je bij voorbaat al weet waarom keuze 1 sneller is dan keuze 2 dan lijkt me het nogal logisch dat je de snelste keuze gebruikt.

En ja ik weet dat leesbaarheid van code ook een argument is maar wanneer je met hetzelfde aantal regels een snellere code kan produceren dan moet je maar leren om de zogenaamde minder leesbare code te begrijpen. Wanneer je het begrijpt is het vanzelf leesbaar.

[ Voor 16% gewijzigd door stekkel op 02-08-2003 02:35 ]

[crisp]

eens met stekkel

Als je ooit eens een app moet schrijven waar het wel op snelheid aankomt dan zijn dit soort dingen gewoon handig om te weten, en vele kleine optimalisaties maken vaak ook tienden van seconden winst in een script. Bij PHP scripts is dit mischien triviaal, maar als je games gaat developpen of grote batches moet schrijven voor legacy applicaties (waar downtime zoveel mogelijk geminimaliseerd moet worden) dan is performance wel degelijk een issue

[marty]

MBV schreef op 02 August 2003 @ 00:08:
Mensen, waar gaat het om? Als je dit soort verschillen (40% blijft maar 2 miliseconden verschil) gaat uitpluizen, kan je dan niet beter je website gaan verbeteren, navigatie etc, zodat hij sneller werkt? Of gaat het om meer dan 212 ( 1/0.00469899177551 = 212) bezoekers per minuut?
Dat soort theoretische vragen is meestal zinloos, ga liever die tijd besteden aan betere programma's!

al eens opgezocht wat tweakers betekent ?

[Soultaker]

Ik ben het echt eens met MBV en de stelling "premature optimization is the root of all evil". Het is veel productiever om je in de eerste plaats te concentren op een goed ontwerp en de bijbehorende nette en overzichtelijke code. Schaalbaarheid is vaak veel belangrijker dan optimale code in een beperkte testomgeving.

Er zit een verschil tussen het schrijven van goede code (die daarom snel is) en het optimaliseren van bestaande code (die snel wordt, door helderheid en generaliteit op te offeren). Uitsluitend in het laatste stadium van de ontwikkeling zijn optimalisaties geoorloofd, omdat je anders de bruikbaarheid van code waar je nog mee verder moet, verpest, en omdat je alleen als het product functioneel compleet is, kunt vaststellen wat de knelpunten zijn.

Dat brengt me bij een tweede punt met betrekking tot optimalisatie: optimaliseer uitsluitend de bekende knelpunten. Zomaar code aanpassen waarvan je weet dat 't beter zou kunnen, is niet productief. Soms wel leuk, natuurlijk, maar daarom nog niet slim. Meestal is slechts een klein deel van de code verantwoordelijk voor de grootste overhead; zoek dat deel dus op en optimaliseer alleen dat.

Verder moet je in een productieomgeving de kosten van betere hardware afwegen tegen die van een ontwikkelaar. Als je een goed schaalbaar ontwerp gekozen hebt, is de kans groot dat je je performance probleem met extra hardware kunt oplossen. Deze mogelijkheid bestaat niet bij alle toepassingen (als je een end-user applicatie oplevert gaat het niet op, want je kunt niet van alle gebruikers verwachten dat ze gaan upgraden) maar bij een website (of een dergelijke service) juist wel.

Niemand zegt dat je suboptimale code moet schrijven, maar doorgaans wordt teveel tijd besteedt aan optimalisaties en te weinig aan een degelijk ontwerp en een onderhoudbare implementatie. Ik pleit dus voor een betere verhouding van onderdelen van het software engineering proces, wat tot een beter product moet leiden.

[ Voor 10% gewijzigd door Soultaker op 02-08-2003 03:42 ]

[sjokki]

Soultaker schreef op 02 August 2003 @ 03:34:
Het is veel productiever om je in de eerste plaats te concentren op een goed ontwerp en de bijbehorende nette en overzichtelijke code. Schaalbaarheid is vaak veel belangrijker dan optimale code in een beperkte testomgeving.

Ik ben het helemaal met je eens. De slechtste code wordt geschreven op het moment dat er aanpassingen gedaan moeten worden aan een script waarvan niemand meer weet hoe het in elkaar zit.

De reden dat ik met die metingen kwam was dat de topicstarter expliciet om 'snellere code' vroeg.

Regular expressions kunnen trouwens in bepaalde scripts wel een bottleneck vormen.

[stekkel]

Soultaker schreef op 02 augustus 2003 @ 03:34:
Er zit een verschil tussen het schrijven van goede code (die daarom snel is) en het optimaliseren van bestaande code (die snel wordt, door helderheid en generaliteit op te offeren). Uitsluitend in het laatste stadium van de ontwikkeling zijn optimalisaties geoorloofd, omdat je anders de bruikbaarheid van code waar je nog mee verder moet, verpest, en omdat je alleen als het product functioneel compleet is, kunt vaststellen wat de knelpunten zijn.

Het gaat hier om het schrijven van goede code die daarom snel is.
Ik gruwel zelf altijd van het te pas en te on pas regular expressions gebruiken terwijl het veel simpeler kan. Regular expressions indien onnodig gebruikt maken de code al helemaal niet leesbaarder.

Wat betreft het aspect dat je alleen kan zien waar de knelpunten zitten wanneer het product functioneel compleet is is een beetje onzin.
Wanneer je begint met een product moet je een idee hebben waar mogelijke knelpunten zitten en daar op anticiperen. Wanneer je dat niet doet ben je achteraf meer tijd kwijt met optimalisaties omdat je geen rekening hebt gehouden met voorspelbare knelpunten, nog maar niet te spreken over mogelijke foute keuzes in de gekozen architectuur.

Dat brengt me bij een tweede punt met betrekking tot optimalisatie: optimaliseer uitsluitend de bekende knelpunten. Zomaar code aanpassen waarvan je weet dat 't beter zou kunnen, is niet productief. Soms wel leuk, natuurlijk, maar daarom nog niet slim. Meestal is slechts een klein deel van de code verantwoordelijk voor de grootste overhead; zoek dat deel dus op en optimaliseer alleen dat.

Beetje open deur, maar uiteraard mee eens. Voor flexibiliteit onderhoudbaarheid van code
is het vaak belangrijk on goed na te denken over een bepaalde architectuur m.b.v. classes. In php is het aanroepen van class methods trager dan normale functies maar dat betekent niet dat je daarom maar moet afzien van classes. Bovendien kan je in class methods ook proberen optimale code te schrijven.