On his CodeUptopia blog Jani Hartikainen has posted a great article with some of his thoughts about why fixing bugs is so slow and includes a few suggestions on how to make it happen faster and streamline the process for the future.

Have you ever wondered why sometimes fixing bugs seems to take much longer than it should? When you finally find the problem, it turns out all you need is one small change. Yet, it took a lot of time to find what’s going on. This happens to me more often than I’d like.

[...] Why is it that sometimes fixing bugs takes a lot of work even when the problem is simple, and other times, it’s really quick to fix the problem – maybe even when it isn’t so trivial? Is there something we can learn from the bugs that are easy to fix, so that we could spend less time fixing bugs in general?

He starts off by describing a typical bug fixing process after the initial discovery and reporting of the issue down to the actual fix being deployed. He then breaks down each of these six steps and provides more context around them:

• Understanding the problem
• Reproducing the bug
• Finding the problematic piece of code
• Identifying the root cause
• Fixing the bug
• Ensuring the bug is fixed

He then goes back and talks about the pain points in this typical process citing things like a lack of good information around the bug and the time constraints that often come with the "time to fix" allowance. He makes some suggestions about how to gather better information around the issue before the fix begins and points to effective logging as one possible source. He also talks about how unit testing can help verify the bug is actually fixed and help to prevent and locate future issues.

On the Acquia blog they've posted another in their guest post series, this time from Richard Miller, a Senior Technical Consultant with SensioLabs (the people behind the Symfony framework). In this new post he talks about how the performance of PHP is getting better and why.

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

He looks at "a brief history" of the language and the major milestones that have lead to the biggest performance gains over the years. He also talks about some of the alternatives out there to "normal PHP" for execution including the HHVM and HippyVM projects. He ends the post with a warning, though - be careful of fragmentation and separation of the community based on these different tools and embrace things like the language specification to keep things on an even keel.

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?

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?