Re: Speed comparison of PHP vs. PERL (not conclusive)

"Peter" <newsaddress@saracenvsu.org.uk> wrote in message news:20020605080308.2235.qmail@pb1.pair.com... > You mention that you could have written the PHP code in a more efficient way > using continue(). Why not time this as surely a built in function would be > quicker than one written in the code. > -- snip to my old test results -- > > > > [dewin@ulysses profiling]$ time ./prime.php > /dev/null > > > > real 0m14.465s > > user 0m8.610s > > sys 0m0.070s > > > > [dewin@ulysses profiling]$ time ./prime.pl > /dev/null > > > > real 0m5.302s > > user 0m3.180s > > sys 0m0.000s My intent upon writing this program was to compare the relative speed of execution between PERL and PHP, however it's been established that it's not really a valid test as PERL is optimized for looping whereas PHP is better in other areas. (Personally, I don't know the PHP source very well but I'm curious as to whether trying to bring it closer to PERL's speed is an eventual design goal -- I DO have some tightly-looping PHP code that does see frequent use and it would be nice to speed it up. (but my own code could be sped up with a better algorithm too -- I'd ask about it but it's not a priority to me at the moment)). My intent was to make the scripts as equal as possible so the results would reflect pure speed and not capabilities of the language. (Of course, I've been told PERL has an equivalent to PHP's continue(n) syntax, so the issue is moot.) However, for the sake of completeness I'll profile both variants of prime.php again: Old method (set temp val, break, test temp val, continue if temp val set): [dewin@ulysses profiling]$ time ./prime.php > /dev/null real 0m14.304s user 0m8.520s sys 0m0.060s new method: (continue(2);) [dewin@ulysses profiling]$ time ./prime.php > /dev/null real 0m14.402s user 0m8.620s sys 0m0.030s Surprising? To be fair, I only timed the old method once and took the average from three times on the new method (I changed my only copy of the code and didn't feel like changing it back to retest the old method). The times shown in my original tests (above) probably more accurately reflect the old method than the current ones. That being said, it looks like continue(2) is actually a tiny tiny bit slower (we're talking around 0.010s over a 10000-iteration loop on a 700 mhz machine here) than doing it by hand the old way. With an amount that small though, I'm more inclined to believe it's just statistical error/random variance than anything else. -- Daniel Grace