Why is the title talking about memory leaks? The listed benchmark is comparing "PHP/O+ memory usage". Memory usage isn't memory leaks.
Just because something uses a lot of memory doesn't mean it's leaking memory. Only when that used memory never gets freed or reused you can talk of leaks.
The linked benchmark isn't taking this into account /at all/. It's just measuring memory usage.
From my own experience with PHP, while it's using a lot of memory at times, it doesn't usually leak it, unless you produce code that cause it to leak (circular references before the GC days), but that's really the programmers responsibility.
The last time I suffered a huge memory leak in PHP was with HTML Purifier on PHP 5.2. It was impossible to process more than a few documents at a time, even from the CLI, because HTML Purifier seemed to leak every byte of memory it used. Lots of circular references.
With PHP 5.3 with the new GC and the latest version of HTML Purifier, there is no memory leak anymore. PHP has come a long way since the days when you had to respawn Apache processes every 500 requests.
I'm a bit suspicious that Wordpress is listed under req/sec, but is missing from the memory usage table. Hopefully an oversight... unless Wordpress is still the king of memory hogs :)
I mean, that's supposed to be the native Opcode Cache with PHP!
My WAMP distro (http://www.devside.net/server/webdeveloper) is switching to it, as it's finally stable enough to use in production (eAccelerator had it beat for some time).
Also, Zend Optimizer only works with PHP as a non-thread-safe / FCGI process in PHP 5.3, so there goes it's use under the prefered Windows mod_php setup (Windows handles threads really well). The only time you want to use FCGI on Windows is if there are serious memory leaks.
It's hard to ignore Windows as a PHP paltform considering it's the majority of the webdev segment for PHP and about 1/3 of production for PHP.
Most opcode caches are within a couple percent in performance of each other, I wouldn't expect the commercial Zend product to be much better or worse than APC performance.
Since Dmitry Stogov (the benchmark poster) invented Turck MMCache and was hired away by Zend, it makes sense he is benchmarking with zend ;-)
.. It's hard to ignore Windows as a PHP paltform
Wait - What? I use both Windows and Nix, and have always moved to Nix for better speed and security. Do you have links to this statistic?
I would prefer to use 64Bit, but there is no current support for it in PHP.
People from Apache, PHP and MySQL have published stats (in conferences and points) that show the Windows and Linux deployment figures for downloads, development work, and production deployments, over the years.
The majority of dev work (like local website development and testing) with Apache, PHP, and MYSQL was under Windows. 1/3 of production work was also Windows. This was several years ago and I have seen these numbers increasing in Windows favor.
<b>Although PHP is universally thought of as implying Linux, Apache and MySQL, nearly 7% of PHP sites [when counting by ip address] run on Windows. This has doubled over the last year</b> (from Netcraft: http://news.netcraft.com/archives/2003/08/30/php_growing_sur... ).
PHP on Windows grew much more later on, what with Microsoft even making several specific changes to IIS et all to accommodate it better.
In our PHPCR tests, it looks like PHP 5.4 is about as fast (or slightly slower) than 5.3, but uses between 25% to 50% of the memory. Note however that this is with heavy usage of compiled PHP extensions like midgard2.
When I was in medical school, I ran into this level of pedantry all the time, especially on the surgical services (We don't "do" surgery, we "perform" surgery; we "do" operations!). Or maybe it's the other way around. Either way, it made me a little sad. Consider ignoring all the literal misappropriations you encounter daily and simply listen to people. It makes for a much more pleasant experience.
> Consider ignoring all the literal misappropriations you encounter daily and simply listen to people.
How about both? People have no hesitation about correcting a person's programming syntax, and are usually thanked. Why not apply the same rules to English syntax? Both are important to one's effectiveness.
The title of this post is amusing. Only "less memory leaks"? None would be nicer. (Also "fast" is relative. When you're known for one of the slowest interpreters getting large performance increases is easy. It would be better to bench against something that really is fast, like the JVM for example.)
Python & Ruby are both slower interpreted languages than PHP, for all their lovely syntax.
The JVM is slower to develop for, and when probably 50% of projects on the web are stuff that's built in less than 2 months, using the JVM adds too much complexity where it really isn't needed.
If you want speed (almost) as good as the JVM without using an interpreted language, use Node. Unless of course you only know the one language from your CompSci days..
Compare it with a micro-cached Varnish or nginx .. caching is outside of the "speed" parameters. Of course, you could take a look memcached if you want :)
I can't find the reference I remember but it fits roughly with the link posted (the scale seems to match the max times rather the average times). The differences were tiny but the order was PHP, Python, Ruby if I remember correctly (PHP was in front, PR may have been switched).
In the case of Mako at least, caching doesn't mean caching in the way you mean it. It's more akin to opcode caching in PHP, saving the actual python code generated from the template, not the result. Just saves from reparsing the template every time it's rendered, but the actual template logic still runs.
I like JRuby a lot, in fact it's my favourite scripting language on the CLI, but while it's fast to run its damn slow to compile (remember it still has to compile to JVM bytecodes).
Just because something uses a lot of memory doesn't mean it's leaking memory. Only when that used memory never gets freed or reused you can talk of leaks.
The linked benchmark isn't taking this into account /at all/. It's just measuring memory usage.
From my own experience with PHP, while it's using a lot of memory at times, it doesn't usually leak it, unless you produce code that cause it to leak (circular references before the GC days), but that's really the programmers responsibility.