Slashdot Mirror
PHP 5.2.2 and 4.4.7 Released
daeg writes "PHP 5.2.2 and 4.4.7 have been released with a plethora of security updates. Many of the security notifications come from the Month of PHP Bugs effort, and range from double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize(), to input validation flaws that allow e-mail header injections, with an unhealthy sprinkling of other bugs and flaws fixed. All administrators that run any version of PHP are encouraged to update immediately."
What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.
Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.
The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.
There are plenty of good criticisms for PHP (and every other language), but performance is only a factor in PHP web apps when the programmers do really stupid things.
The global economy is a great thing until you feel it locally.
Sure, I'll give you some.
Inconsistent function naming (underscores):
substr_compare() vs.
strcmp()
More inconsistent function naming (verb location):
file_get_contents() vs.
get_html_translation_table()
Even within the same extension:
imagesetstyle() vs.
imagecolorset()
Flipped haystack and needle:
strpos(haystack, needle) vs.
in_array(needle, haystack)
Speed:
Scutigena Computer Language Performance Comparison (see graphs)
There used to be another site that you could compare one language's speed relative to another that also showed PHP as one of the slowest. I can't seem to find it now, though. Also PHP5 might compare a bit more favourably, but this is all I could find after a quick Google search. Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.
I think PHP is overall a fairly decent language; I've used it for many years with great success. But it does have major problems, and it would be nice for them to get fixed instead of pushed aside. (I read some minutes from a PHP 6 meeting a while ago where they touched on the issue of consistency, and the PHP Group decided that it wasn't important enough to fix. It's really annoying to me to need a PHP-aware IDE or a manual always handy to program in a language because the arguments and function names are so non-uniform.)
[insert witty comment here]
You're comparing two completely differnet language types. You might as well compare Java and C++.
Compared to other interpreted (e.g. parse tree is built on the fly rather than by a compiler) languages like Python or Ruby, PHP is about average.
Compare PHP to the CLR (or Mono) or to the JRE, and PHP is going to be way slower.
But calling PHP slow because of some benchmark is just bull. Yes, Java or
The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove? It proves that application design and system architecture is FAR more important than what platform you choose. You can run benchmarks all day long, but that doesn't change the fact that Wikipedia does far more with far less than most websites out there - and they do it with PHP.
I serve over 10 million pageviews a month on WS Network using PHP, MySQL, and a virtual server with 50MB of memory, a fraction of a 2.4GHz P4, and 100MB of swap. My informal load testing indicates that I could handle as many as 30 pageviews per second (80 million per month) with my current hardware and DB setup.
Maybe I could do more with J2EE or ASP.NET (or, perhaps I could do far less - ASP.NET and J2EE aren't as easy on memory as PHP for small apps). But the fact is that I am doing a hell of a lot already considering the very limited hardware I'm running on.
PHP code execution performance is not, and has never been, a major issue in my experience. It's the same way with Python, Perl, Ruby, and any other "scripting" language. The fact is, you're not going to write an H.264 codec or a PS3 game in Python. But many, many applications are not constrained by CPU performance. 8-core servers are now cheap. 16-core servers will be soon. Changing your language might give you 10x better performance. But architecture and algorithm improvements will probably get you much, much more.
"Performance isn't a problem until it's a problem."