On the PHPClasses blog today the question is posed "can .NET make PHP run faster than the official PHP implementation?" (relating to the use of the Phalanger tool to compile PHP down to .NET assemblies.

Recently Phalanger 3.0 was released introducing numerous improvements in terms of compatibility with the PHP 5.3, interoperability with .NET platform implementations including Mono on Linux, and probably most importantly performance improvements. [...] What motivated this article was that a PHP developer named Rasmus Schultz went on the php.internals mailing list and proposed to switch the official PHP implementation based on Zend for another based on Phalanger.

The post includes some benchmarking results of requests made to a WordPress instance running on various PHP platforms. The Phalanger version came in around 2 seconds faster (average, obviously) than the PHP FastCGI setup. Also included are two suggestions for future PHP versions (v6 anyone?) that could help the language perform even better: Thread-safety for running with less memory waste and the inclusion of a JIT (Just in time compiler - of which a few are mentioned specifically.

Kevin van Zonneveld has a new post to his blog revising an older post talking about session management with PHP and how limit the resources needed by them. In this post he points out another method - holding the sessions in RAM rather than on disk.

sing 2007 article Create turbocharged storage using tmpfs, we can defeat some of this over-engineering and take a simpler approach to speeding up sessions in PHP. We'll store them decentralized in memory by mounting RAM onto the existing /var/lib/php5 session directories throughout your application servers, which I will call nodes from now on.

He includes the commands you'll need to make a directory live in the RAM of your machine and how to migrate the existing sessions to this new data store. He covers some of the advantages of this approach (including that there's "less tech" involved so it's easier to manage). There is one point of failure he points out - that it wouldn't be a solution you could use for websites that might need to bridge sessions across machines.

On the Java DZone.com section today there's a "which is faster" post comparing PHP, Java and Python. No, it's not quite what you're expecting - I'd suggest reading on.

Sigh. What a difficult question. There are numerous incarnations on StackOverflow. All nearly unanswerable. The worst part is questions where they add the "in general" qualifier. Which is "faster in general" is essentially impossible to answer. And yet, the question persists. There are three rules for figuring out which is faster. And there are three significant problems that make these rules inescapable.

His three rules are:

• Languages don't have speeds. Implementations have speeds.
• Statistics Aren't a Panacea.
• Benchmarking Is Hard.

He seems to hit most of the issues with these sort of "faster" posts up front and notes that, while benchmarks can be run on a lot of different aspects about the languages, the results depend on how you slice it. His suggestion is, instead, to not try to compare the languages in a grand sense. Take each of them and compare them on specific tasks and let those results stand alone. Each of the three languages is going to be better at something than the other two.

Josh Holmes (a Microsoft Evangelist) recently gave a presentation about getting PHP applications, specifically WordPress to work better on a Windows-based platform (whether it be running on a physical server or something like Azure).

I talked about the amazing improvements in FastCGI over the past few years, the Web Application Gallery and Web Platform Installer (WebPI), URL Redirect, WinCache and many other things that Microsoft is doing to embrace open source technologies.

The slides for the talk are over on Slideshare but if you want something a little more engaging, check out the webcast from php|architect this coming Friday (April 9th) by Mark Brown and Ruslan Yakushev on the same subject.

While running some benchmarks on some of the more popular PHP frameworks, Paul Jones came across something interesting - a PHP request was handled faster than a static HTML request.

With the help of the great guys at Slicehost.com, I am attempting to run my benchmark series on a virtual private server, to compare with EC2. However, I'm seeing a very strange result for the baselines: a PHP page delivers more requests-per-second than a static HTML page.

According to his results, his runs of ab (the Apache benchmarking tool) showed that requests against the index.html file (versus the index.php) came in at almost 400 requests per second slower. As it turns out, though, the problem of the skewed results wasn't in the serving up of the requests but in the ab tool itself. He picked up another testing tool, seige, and ran that with the same requests and got more correct results.

Etienne Kneuss has posted about a new part of the Standard PHP Library that creates arrays that are up to thirty percent faster than normal methods - SplFastArray.

Antony got the idea to implement a C-like array wrapper in SPL: SplFastArray. The main advantage of that class is performance, it's indeed faster than PHP arrays. How so? No free lunch: The speedup comes from the fact that non-numeric indexes are not allowed and that the array is of fixed size.

The code sample shows the setting of the size for the array (and changing it) with a var_dump of the output result. This method is always faster than normal arrays, it just varies how much from system to system (anywhere from ten to thirty percent).

Nick Halstead asks an interesting question on his blog today - "Do faster typists make better coders?"

I have been able to touch type since about age 12 and can manage about 100 words per minute when faced with blocks of text to copy and even faster if I am just writing code. [...] Programming in C meant a lot more typing of parenthesis and a lot more thinking about the structure of the code.

PHP has introduced another set of typing problems with a lot more use of < > and a much higher mixture of variables/functions/parenthesis plus the added bonus of trying to remember a single function from a choice of 3000+.

Several of the comments on the post suggest that it could be helpful to productivity, but shouldn't be focused on too much. After all, what really matters is the programmers skill, right?

Continuing in their "plugin of the week" series, the Symfony blog presents a new plugin that can help to make your Symfony application up to 70 percent faster than it already is.

I'd like to tell you a little success story about using sfOptimizerPlugin. I did many things in my "public" application to optimize performance [and end up having] an average execution time of ~150ms per page, wich leads to ~100ms in the production environment. A little bit slow, I think.

After [installing the plugin and] running $php symfony optimize public staging over the environment, the execution time was reduced by 50ms from ~150ms down to ~90ms, nice. And even the production environment acts faster now, with only ~30ms to serve pages, very nice - 70% faster!

He even suggests using the sfOptimizerPlugin in a cron job on a server to help keep things constantly optimized.

A new post to the SitePoint PHP Blog today (from Paul Annesley) looks briefly at how, with the help of XDebug, you can make your applications lighter and faster.

So we've got potentially slower code, and we can no longer just open up our simple PHP script and follow its execution from the top of the file to the bottom. How do we figure out exactly what's going on inside?

He doesn't go through the installation of XDebug, but he does give an example (complete with screenshots) of how to use it in conjunction with two other applications - WinCacheGrind for Windows users and KCachegrind - to work with the output XDebug produces.

As Mike Potter mentions in his new blog entry, Flash, Flex and PHP just got a great leg up when it comes to using the combination:

Patrick Mineault, who runs the AMFPHP project, has released a new version of AMFPHP 1.9, beta 2 now. However, the real big news in his blog post was the news that there is now a C based AMF extension for PHP.

According to the test data Patrick gives, the speed jump is well worth implementing the different functionality - a 100% boost, in fact, than the standard PHP version of AMFPHP. Check out Patrick's blog for the rest of these amazing stats.