Php 5.4 vs 5.3: is really fast and with less memory leaks | Hacker News Reader

Php 5.4 vs 5.3: is really fast and with less memory leaks

news.php.net

67 pointsmariuz31 comments

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.

Minor nitpick: the fact that something uses more memory does not mean that it "leaks", using the common definition of the word "leak".

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 :)

Wouldn't surprise me, the whole thing is fairly monolithic and tightly coupled.

Is "Zend OptimizerPlus" any form of an opcode cache?

Ah it is indeed an opcode cache, just wasn't familiar with it as a commercial product

http://files.zend.com/help/Zend-Server-IBMi/optimizer_plus_c...

Good to see the performance boost is maintained with an opcode cache and not negated.

I'd much rather see this with APC benchmarks.

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.

Where do they get those stats from? Most people deploying or developing on linux will get the packages for all of those things from their distro.

Even as early as 2003:

<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.

"Less" memory leaks -- would that be the same number of memory leaks but each of them smaller, or does the author actually mean fewer memory leaks?

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.

English less is to fewer as JavaScript == is to ===. So if you see someone misuse a term, consider informing them.

// less is for general mass, fewer is for countable nouns; == is for general comparison, === is for comparable things of the same type

Less grass. Fewer blades of grass. Boom! Grammar.

Miguez de Icaza explains here why you're not getting laid (much):

http://tirania.org/blog/archive/2011/Feb-17.html

I suspect personal attacks do more harm to one's social standing than weighing in on an already in progress grammar discussion.

> 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.

Actually, the article seems to mean "lower memory usage". It says nothing about memory leaks.

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..

> Python & Ruby are both slower interpreted languages than PHP

Source? That's not what the Programming Language Benchmark Game says...

http://shootout.alioth.debian.org/u64/which-programming-lang...

Although that's probably without an optimiser at all.

Maybe that should be qualified "in a web context".

Still a big [citation needed]. Compare with something like cached Mako templates in Python and I seriously doubt it's competitive.

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).

I'll try get a link but I doubt i'll find it.

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.

Or use JRuby to get the advantages of ruby with the speed of JVM (http://jruby.org/).

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).

I think people often just don't know about recent developments.

PyPy is at least as fast as Node, and Rubinius is also very fast.

Reply on news.ycombinator.com