Sure, you could put it that way.  When benchmarking something you really
should benchmark stuff that you actually care about.  Benchmark PHP
spewing out a web page after making a couple of SQL queries, for example.
That's typical usage, so that is what you should benchmark.  Very few PHP
scripts are going to loop a couple of hundred thousand times to do
something.

-Rasmus

On Fri, 31 May 2002, Ilia A. wrote:

> Does this mean that running a comparison benchmarks between PHP and any other
> language would in many cases show PHP to be slower simply because it's
> looping code is slow? Unless, timing is done on a speed of PHP being able to
> spew out webpages via the webserver with a webserver benchmark tool such as
> apachebench?
>
> Wouldn't that cause any benchmarks trying to guage the speed of PHP virtually
> meaningless because of the 'loop' overhead, which is clearly great enough to
> make PHP way slower in comparison to Perl for example?
>
> Ilia
>
> On May 31, 2002 05:38 pm, Rasmus Lerdorf wrote:
> > Not very surprising.  Perl's looping code has always ben faster than
> > PHP's.  Highly iterative loops is really not what PHP is geared for.  You
> > are not going to write a Mandelbrot algorithm in PHP.  You write it in C
> > and drop in a super-quick extension into PHP and call mandelbrot().
> >
> > -Rasmus
> >
> > On Fri, 31 May 2002, Daniel Grace wrote:
> > > This all started in a little debate between me and a friend of mine who I
> > > think is as much a PERL zealot as I am a PHP zealot (I was briefly
> > > pondering the idea of a Win32 API extension for PHP), and the results
> > > were rather surprising -- to me, at least..
> > >
> > > It all started when I asked him what PERL had that PHP didn't in terms of
> > > language (not taking community, modules, etc. into an account). We both
> > > believed that the two would be very similiar in speed -- he thought PERL
> > > would be a little faster but not enough to be noticeable. For the first
> > > test, I went with a program that computed prime numbers between 2 and
> > > 10000, using no form of caching or anything like that. I gave him the PHP
> > > source with the task of writing something in PERL as close to the
> > > original PHP source as possible. The results:
> > >
> > > (note: I didn't know if PERL had PHP's continue(2), hence why I used the
> > > slightly less efficient method here:)
> > >
> > > prime.php:
> > > #!/usr/bin/php -q
> > > <?php
> > >
> > > echo "2\n";
> > >
> > > for($check = 3 ; $check < 10000 ; $check += 2) {
> > >         $prime = 1;
> > >         $half = (int) $check / 2;
> > >         for($against = 2 ; $against <= $half ; ++$against) {
> > >                 if(!($check % $against)) {
> > >                         $prime = 0;
> > >                         break;
> > >                 }
> > >         }
> > >         if($prime) echo "$check\n";
> > > }
> > >
> > >
> > > prime.pl:
> > > #!/usr/bin/perl
> > > # print "2\n";
> > > my $num;
> > > for ($num = 3; $num < 10000; $num+=2)
> > > {
> > >         my $prime = 1;
> > >         for $check ( 2 .. int($num/2) )
> > >         {
> > >                 if ($num % $check == 0)
> > >                 {
> > >                         $prime = 0;
> > >                         last;
> > >                 }
> > >         }
> > > #        print "$num\n" if $prime;
> > > }
> > >
> > >
> > > The test machine is an AMD Duron 700 MHz using an a-bit KT7A motherboard
> > > with 256 MB of PC100 SDRAM. uname -a reports "Linux ulysses.venura.net
> > > 2.4.17-ulysses1 #1 Sat Dec 29 14:44:46 PST 2001 i686 unknown", PHP 4.2.1
> > > was configured with --enable-inline-optimization --prefix=[somepath],
> > > PERL 5.6.1 was configured with -O3 (among other options) (PHP compiles
> > > with -g -O2 with no 'easy' (at-configure-time) way to change that, to my
> > > knowledge).
> > >
> > > Both programs were ran once normally to verify they actually generated
> > > prime numbers, and then the bash "time" command was used to time them,
> > > piping their output to /dev/null to prevent that from being a factor. I
> > > re-ran the tests a few times with results consistently similiar to those
> > > listed here:
> > >
> > > The 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
> > >
> > >
> > >
> > > A second system, with PHP compiled the same way and a PERL 5.6.1 binary
> > > distributed by Red Hat, 1.2 ghz with 442 MB of RAM:
> > >
> > > [root@mrr-016 law]# time ./prime.pl > /dev/null
> > > real 0m2.078s
> > > user 0m2.040s
> > > sys 0m0.010s
> > >
> > > [root@mrr-016 law]# time ./prime.php > /dev/null
> > > real 0m5.512s
> > > user 0m5.430s
> > > sys 0m0.010s
> > >
> > >
> > > Comments? I was expecting the numbers to be very similiar -- rather
> > > shocked that the PERL ended up being about 2.5x as fast as PHP was.
> > >
> > >
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to