preg_match digits?

On 1 Jun 2004 22:33:10 GMT, Tim Van Wassenhove <euki@pi.be> wrote:

>In article <40BCDEDB.F664DB67@nospamun8nospam.com>, Westcoast Sheri wrote:
>> Tim Van Wassenhove wrote:
>>> 1-) It works.
>>> 2-) I presume it's more efficient than using regular expressions.
>>> Up to you proove me wrong :D
>
>> Answer:
>>
>><?php
>> $string = 'a 20adiidkk4kidid39399399dkkdkkkdk';
>> $dig = substr(preg_replace("/\D/",'',$string),0,2);
>> echo $dig;
>> ?>
>>
>> Takes .000027 to run.
>
>Feel free to run the following script a few times ;)
>test1 always had a smaller execution time than test2 when i tried....

Actually, there's a bug here...

>$start = microtime();
>foreach($strings as $string) {
> test1($string,2);
>}
>$end = microtime();
>echo '<br>total: ' . ($end - start);
^

Missing $.

Notice: Use of undefined constant start - assumed 'start'

Minus isn't defined on strings, so it'll cast 'start' to a numeric type. A
string with no numeric characters evaluates to zero when cast to a numeric
type. microtime() returns a string in the following format:

<microseconds past second> <unix timestamp>

... with a space in between.

Casting that to a numeric type evaluates to the first numeric part, up to the
space. So you end up with microseconds past the second, minus zero.

Unfortunately this bears no relationship to actual execution time :-(

Suprisingly, after fixing the bug, the preg_replace method turns out about 3x
faster than the loop.

$start = microtime(true);
foreach($strings as $string) {
test1($string,2);
}
$end = microtime(true);
echo '<br>total: ' . ($t1 = $end - $start);

$start = microtime(true);
foreach($strings as $string) {
test2($string);
}
$end = microtime(true);
echo '<br>total: ' . ($t2 = $end - $start);
echo '<br> t1/t2 = ' . round($t1/$t2, 4) . 'x';


total: 0.004275
total: 0.001488
t1/t2 = 2.873x

--
Andy Hassall <andy@andyh.co.uk> / Space: disk usage analysis tool
http://www.andyh.co.uk / http://www.andyhsoftware.co.uk/space

In article <fk1qb0p0oedj0jgfn7qbe2077akv6b6hv8@4ax.com>, Andy Hassall wrote:
> Suprisingly, after fixing the bug, the preg_replace method turns out about 3x
> faster than the loop.

*blush* Now, that changes my vision on regular expressions being "slow".


--
Tim Van Wassenhove <http://home.mysth.be/~timvw/contact.php>

Matthias Esken wrote:
> ... and you're my god. :-)

LOL

I respectfully ask you to choose better gods ...


<OT LEVEL="EXTREMELY HIGH">
Like no god at all
</OT>

--
USENET would be a better place if everybody read: : mail address :
http://www.catb.org/~esr/faqs/smart-questions.html : is valid for :
http://www.netmeister.org/news/learn2quote2.html : "text/plain" :
http://www.expita.com/nomime.html : to 10K bytes :

Tim Van Wassenhove wrote:

> In article <fk1qb0p0oedj0jgfn7qbe2077akv6b6hv8@4ax.com>, Andy Hassall wrote:
> > Suprisingly, after fixing the bug, the preg_replace method turns out about 3x
> > faster than the loop.
>
> *blush* Now, that changes my vision on regular expressions being "slow".

*giggle* nya nya nyaaaa nya

On 1 Jun 2004 22:55:58 GMT, Tim Van Wassenhove <euki@pi.be> wrote:

>In article <fk1qb0p0oedj0jgfn7qbe2077akv6b6hv8@4ax.com>, Andy Hassall wrote:
>> Suprisingly, after fixing the bug, the preg_replace method turns out about 3x
>> faster than the loop.
>
>*blush* Now, that changes my vision on regular expressions being "slow".

Wasn't the result I was expecting, either. Although I can see reasons for it,
e.g. PCRE is all compiled from C, whereas the loop is all PHP so there's more
overhead.

Given the equivalent loop and PCRE regex both in C, I'd have thought the loop
would win hands down.

--
Andy Hassall <andy@andyh.co.uk> / Space: disk usage analysis tool
http://www.andyh.co.uk / http://www.andyhsoftware.co.uk/space