I agree that in most cases it makes more sence at seing the webpages per
second benchmark rather then a timing of some artibtrary benchmarks that for
example seeing how long it take to pick prime numbers. Since in the end it
matters how quickly you can get the data to the user, in case of perl
programs there would be the overhead of spawning a cgi program, (unless
mod_perl is used) which would negate much of the speed improvment gained by
Perl.
All that said, loops are very very common in PHP, and are used with virtually
in any script that uses a database wether it be SQL or flatfile to loop
through the result set.
Since this appears to be a known performance issue, perphaps it is something
the PHP Development team could consider improving for PHP 5.0
Ilia
On May 31, 2002 06:00 pm, Rasmus Lerdorf wrote:
> 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
