PHP is getting Faster

Competition is helping to drive big performance gains in PHP. Alternative ways of running PHP are becoming viable and with them is coming accelerated speed.

Why worry about performance?

PHP is not the fastest language in which we could write web applications, yet we continue to do so for many other reasons. Pure speed of a language is rarely the main deciding factor for many projects. Developer productivity, for one thing, is usually more important. And in many applications the bottlenecks will not be in the application code; instead it is where interaction with other systems takes place. For example, communicating with databases, APIs, and message queues all take time.

So why worry about the speed of the language at all? Well, application architecture is improving and we are finding ways to avoid all those other bottlenecks. For example, better caching, asynchronous processing and eventual consistency all help, but also make application code performance more important. Trying to gain speed through profiling and optimising code can be a long and tedious process. Thankfully, improvements in the speed of the language itself give us an improvement in these other areas for free.

So why is PHP slow in comparison with some other languages? PHP is a dynamic, interpreted language. This means that it is not compiled to machine language but rather read at runtime. PHP also has a share-nothing architecture, so on every request it interprets everything from fresh. The consequence of this is that performance is not as good as for compiled languages, but it also allows for features that compilable languages do not.

Not needing to compile PHP can help with developer productivity in a few ways. It allows for shorter feedback cycles when developing – the results of changes to the code can be seen immediately without any compilation stage needing to be run first. There is less need to worry about garbage collection and memory use. Debugging of runtime errors is made easier, because you can directly identify where they occur in the source code. It also allows for dynamic code such as variable variables, dynamic types, and so on, though care needs to be taken with these to avoid making your application difficult to test.

A bit of history

PHP grew out of some CGI binaries written in C by Rasmus Ledorf. To be able to embed HTML and other web-specific tasks like form handling, he added parsing of a simple Perl-like syntax. This parser for PHP was rewritten by Zeev Suraski and Andi Gutmans for the release of PHP3. Version 4 of PHP saw the Zend engine - a completely new way of running PHP - introduced. PHP 5 brought with it the 2nd version of the Zend engine. Performance has increased through all these releases.

The Zend engine parses PHP code and turns it into opcodes, which are then interpreted. A big performance boost has long been available by caching this conversion to opcodes. Until version 5.5 of PHP, this caching needed extensions to PHP - the most used being APC. As of 5.5 PHP opcode caching is now part of the core.

Zend PHP became the de facto version of the language and the engine on which it runs. There have been alternatives to this over the years but nothing that has caught on with any real success.

Alternative ways of running PHP

A significant attempt to replace the Zend engine was HipHop, Facebook’s attempt to create a way of compiling PHP to C++, motivated by the large amount of PHP that they are using. This meant it would be more difficult to rewrite it to something else than to find a way of making it run faster. They also find that they are able to be more productive writing in PHP than in static compiled languages.

HipHop's major drawback, which lead to its deprecation, was not being able to use it as a drop-in replacement for Zend. The workflow of the conversion and compilation works differently from the normal process for working with PHP. It could not perform runtime interpretation, so it did not support features of PHP that needed it. This limited it to a subset of the language. Facebook nevertheless had some success in reducing server overhead, but there was only limited adoption by others.

Facebook’s later attempt at addressing this, however, has been much more successful. HHVM (HipHop Virtual Machine) has taken the approach of JIT (Just in Time) compilation. This is in contrast to the Ahead of Time Compilation done by HipHop. HHVM compiles PHP to byte codes that are then interpreted by the virtual machine. JIT may not be as quick, but it does not prevent HHVM supporting PHP’s dynamic features.

This means that HHVM is a real prospect as an alternative engine for PHP. Efforts are being made throughout the PHP community to get major frameworks working with HHVM [Ed. note: Drupal + HHVM&nbsp is working pretty well as of November, 2014. See also "Running Drupal on HHVM" by William Hurley at Forum One], which has removed what would have been a big stumbling block for adoption.

Another project, HippyVM, is providing a similar approach to creating an alternative virtual machine for PHP. It is not yet ready, but is again aiming for completeness - making it a potential serious drop-in option. Its proponents are claiming that it is even faster than HHVM.

What does this mean for the Zend Engine?

Is it the end for the Zend Engine? Not whilst it wins on ease of getting up and running, along with its widespread support across hosting solutions. More than that, though: HHVM has thrown down the the gauntlet. A major rework of the engine will be the basis of PHP 7, the next major release. This new version, known as php-ng, competes with HHVM for speed, as well as introducing changes that are a step towards a JIT compiler. This suggests that future versions still have that possible direction as a way of gaining yet more performance.

Avoiding fragmentation

So times are exciting for performance in PHP. There are now serious contenders for an alternative engine sparking competition to help push things forward as well. Yet, there is a possible danger in all this: the risk that different engine implementations will lead to different implementations of PHP, where some engines support some features but not others.

This kind of fragmentation may not lead to better engines but instead split developers into needing to choose between them. One thing that can combat this is a formal specification for the language. Such specifications exist for other languages, and allow the creation of different compatible runtimes. This is quite an undertaking for PHP since it is not a designed language, but one that has grown organically. The HHVM team have recognised the importance of this and has responded by creating a specification for PHP.

For the first time, there are genuine contenders for alternative ways of running PHP. The competition between these is already seeing some significant performance increases, which seems to be something that is here to stay with ongoing benefits accruing for all of the PHP community.

Guest author dossier

• Name: Richard Miller
• Twitter: @mr_r_miller
• Website: richardmiller.co.uk
• Work affiliation: SensioLabs UK
• FOSS role: "Most of my FOSS involvement is in the Symfony community, blogging, speaking at user groups and conferences and contributing to the documentation."
• Current projects: "PhpSpec, a few behat/phpspec extensions, trying to learn Haskell by writing a tool to generate PHP with it."
• When/which PHP you started with: “4 something, around 2004”
• Richard Miller is Senior Technical Consultant at SensioLabsUK and has 10 years of commercial development experience. Currently focused on the development process using BDD and DDD to facilitate communication and on application architecture. Upsets people by not letting them use inheritance and else statements or methods over a few lines long.