4 ms·

Please back this claim with evidence. There are many things wrong with PHP. Performance is not one of them...it's very quick. I'll start: http://shootout.aliot

Please back this claim with evidence. There are many things wrong with PHP. Performance is not one of them...it's very quick. I'll start: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all http://shootout.alioth.debian.org/u32q/benchmark.php?test=al... Don't sweat it, Ruby's only 50% slower! Proportional results on a faster machine: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

blasdel 18y ago
Bullshit, you linked to rankings (one where PHP's wart is omitted), not results, and your 'faster machine' is many times slower. It's not really so simple: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=ruby http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They go back and forth, but on the meteor contest (which is the alioth people's favorite) Ruby's delta is 260, while PHP's is 36,117 (!!) My main point was that templating frameworks written in PHP are WAY slower than using PHP directly, as you're doing a ton of pointless string operations. Benchmarks back this up, even ROR is >= the PHP frameworks (especially when there's no opcode cache): http://www.avnetlabs.com/php/php-framework-comparison-benchmarks http://www.avnetlabs.com/php/php-framework-comparison-benchm... PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around.
- thomasmallen 18y ago
  In many ways, PHP is itself a framework. Only an idiot would make a high-profile website using ZF or CakePHP. Good luck using straight Ruby for a website. Please don't force me to link to some of Terry Chay's work. There's a very good reason that PHP is used for many high-profile websites whereas Ruby is not.
- wvenable 18y ago
  "writing your own high-level PHP inside PHP" If you're smart, like smarty, you'd compile your high-level PHP into PHP and then you're not doing a ton of pointless string operations.
- zmimon 18y ago
  > PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around. This is what I find most people underestimate about PHP - it scales badly in a slightly unique sense: it scales badly with application size. The problem is incremental and therefore hard to deal with. You start off with one small PHP file. It's wicked fast! 3 months later you have a dozen PHP files and most of them include some common library scripts that are shared between them. It's still fast. A year later your library scripts have grown and grown. Each PHP file is now including 4 - 5 library scripts and those themselves are getting up to thousands of lines long. You try to refactor things but the problem is PHP is such a dynamic and loose language and has such poor abstractions that it's really hard to do that successfully. So soon just to spit some HTML on the page your poor application is interpreting thousands of lines just to render some simple HTML. You look at FastCGI but your cheap web host doesn't support it and then you realize that there are a host of compatibility issues on top that you never thought about when you started that will cause problems. By the time it is mature your PHP application is slow because it is spending all its time parsing the thousands of lines of poorly structured PHP and very little actually rendering HTML. Finally, you look at PHP accelerators like Zend etc. and realize that you're going to have to pay for a commercial solution and the free stack you thought you were building with is not actually free any more and you see that even then there are a bunch of compatibility problems. And then you wish you had built with python ... or java ... or groovy ... or ruby ... or anything else but PHP. It's the poor support for modularization and abstraction combined with the interpreted nature of the language that leads to this.
  - thomasmallen 18y ago
    That's a load of FUD and a fabricated horror story. Computationally intensive business logic should be implemented as a C/C++ extension in any case because PHP is still essentially a web language and a glue language. Rasmus Lerdorf, PHP's creator, has stated as much. Any claim that PHP can't scale is at this point a dead letter, as are more dated claims that Java is too slow, etc.
    - zmimon 18y ago
- igouy 18y ago
  blasdel > but on the meteor contest (which is the alioth people's favorite) Which of the "alioth people" told you the meteor contest was their favourite? blasdel > you linked to rankings (one where PHP's wart is omitted), not results If it's their favourite then why do you think "the alioth people" don't include meteor contest in their ranking? Yes, compare language implementations directly one-against-another for all the benchmarks. As thomasmallen is so keen on the old Pentium 4 machine, compare PHP with Ruby Core 1.9.0 ;-) http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=yarv http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... (Disclaimer - Obviously the benchmarks game webpages are written in PHP)
igouy 18y ago
thomasmallen > Proportional results on a faster machine... What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?
- thomasmallen 18y ago
  I assumed the units to be in seconds, but after looking closer, I can't find a good definition of the units used here. It's the mean of a series of ratios, but the base unit is not on this page. A combination of the lower totals and the fact that one machine was running Gentoo led me to believe that this machine was the faster of the two. (End backtrace of my thoughts)
  - igouy 18y ago
    thomasmallen > A combination of the lower totals Don't you need to know about the numbers that make up those totals? Like if on Pentium 4 the nbody input value is 20,000,000 but on Q6600 the nbody input value is 50,000,000 ... thomasmallen > the fact that one machine was running Gentoo led me to believe that this machine was the faster !
    - thomasmallen 18y ago
      If the results are proportional between trials and are well-accepted (which these seem to be), I'll admit that I'm less interested in the specifics. If I saw aberrations, I would dig deeper, and I'll admit that my analysis was not rigorous.
deleted 18y ago
[deleted]

blasdel 18y ago

Bullshit, you linked to rankings (one where PHP's wart is omitted), not results, and your 'faster machine' is many times slower. It's not really so simple: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=ruby http://shootout.alioth.debian.org/u32/benchmark.php?test=all... They go back and forth, but on the meteor contest (which is the alioth people's favorite) Ruby's delta is 260, while PHP's is 36,117 (!!) My main point was that templating frameworks written in PHP are WAY slower than using PHP directly, as you're doing a ton of pointless string operations. Benchmarks back this up, even ROR is >= the PHP frameworks (especially when there's no opcode cache): http://www.avnetlabs.com/php/php-framework-comparison-benchmarks http://www.avnetlabs.com/php/php-framework-comparison-benchm... PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around.

thomasmallen 18y ago
In many ways, PHP is itself a framework. Only an idiot would make a high-profile website using ZF or CakePHP. Good luck using straight Ruby for a website. Please don't force me to link to some of Terry Chay's work. There's a very good reason that PHP is used for many high-profile websites whereas Ruby is not.
wvenable 18y ago
"writing your own high-level PHP inside PHP" If you're smart, like smarty, you'd compile your high-level PHP into PHP and then you're not doing a ton of pointless string operations.
zmimon 18y ago
> PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around. This is what I find most people underestimate about PHP - it scales badly in a slightly unique sense: it scales badly with application size. The problem is incremental and therefore hard to deal with. You start off with one small PHP file. It's wicked fast! 3 months later you have a dozen PHP files and most of them include some common library scripts that are shared between them. It's still fast. A year later your library scripts have grown and grown. Each PHP file is now including 4 - 5 library scripts and those themselves are getting up to thousands of lines long. You try to refactor things but the problem is PHP is such a dynamic and loose language and has such poor abstractions that it's really hard to do that successfully. So soon just to spit some HTML on the page your poor application is interpreting thousands of lines just to render some simple HTML. You look at FastCGI but your cheap web host doesn't support it and then you realize that there are a host of compatibility issues on top that you never thought about when you started that will cause problems. By the time it is mature your PHP application is slow because it is spending all its time parsing the thousands of lines of poorly structured PHP and very little actually rendering HTML. Finally, you look at PHP accelerators like Zend etc. and realize that you're going to have to pay for a commercial solution and the free stack you thought you were building with is not actually free any more and you see that even then there are a bunch of compatibility problems. And then you wish you had built with python ... or java ... or groovy ... or ruby ... or anything else but PHP. It's the poor support for modularization and abstraction combined with the interpreted nature of the language that leads to this.
- thomasmallen 18y ago
  That's a load of FUD and a fabricated horror story. Computationally intensive business logic should be implemented as a C/C++ extension in any case because PHP is still essentially a web language and a glue language. Rasmus Lerdorf, PHP's creator, has stated as much. Any claim that PHP can't scale is at this point a dead letter, as are more dated claims that Java is too slow, etc.
  - zmimon 18y ago
igouy 18y ago
blasdel > but on the meteor contest (which is the alioth people's favorite) Which of the "alioth people" told you the meteor contest was their favourite? blasdel > you linked to rankings (one where PHP's wart is omitted), not results If it's their favourite then why do you think "the alioth people" don't include meteor contest in their ranking? Yes, compare language implementations directly one-against-another for all the benchmarks. As thomasmallen is so keen on the old Pentium 4 machine, compare PHP with Ruby Core 1.9.0 ;-) http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=yarv http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... (Disclaimer - Obviously the benchmarks game webpages are written in PHP)

igouy 18y ago

thomasmallen > Proportional results on a faster machine... What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?

thomasmallen 18y ago
I assumed the units to be in seconds, but after looking closer, I can't find a good definition of the units used here. It's the mean of a series of ratios, but the base unit is not on this page. A combination of the lower totals and the fact that one machine was running Gentoo led me to believe that this machine was the faster of the two. (End backtrace of my thoughts)
- igouy 18y ago
  thomasmallen > A combination of the lower totals Don't you need to know about the numbers that make up those totals? Like if on Pentium 4 the nbody input value is 20,000,000 but on Q6600 the nbody input value is 50,000,000 ... thomasmallen > the fact that one machine was running Gentoo led me to believe that this machine was the faster !
  - thomasmallen 18y ago
    If the results are proportional between trials and are well-accepted (which these seem to be), I'll admit that I'm less interested in the specifics. If I saw aberrations, I would dig deeper, and I'll admit that my analysis was not rigorous.

deleted 18y ago

[deleted]