From the Joomla blog today there's a new post looking at a few things that you can do to help speed up your site's Joomla installation - simple things that can make a lot of difference.

I'm going to outline some basic rudimentary steps that you can take to optimize your sites performance, and I'd like to hear any other suggestions that you may have ... here's the kicker though, steps users can take WITHOUT making addons to Joomla [...] I also think the majority of Joomla users are running Joomla in a shared hosting environment, so talking about too many server side optimisations could also overwhelm them with steps they are unable to take anyway.

Their suggestions involve enabling caching, keeping up with the latest version, checking on the PHP versions your hosting company is running (or you are) and optimizing some of the contents of the site like images, javascript or CSS. Check out the comments for other suggestions from other Joomla users.

Facebook has made their official announcement about their secretive PHP project today and have scheduled an event for them to give the world more information on the project.

Today I'm excited to share the project a small team of amazing people and I have been working on for the past two years; HipHop for PHP. With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page. Less CPU means fewer servers, which means less overhead. This project has had a tremendous impact on Facebook. We feel the Web at large can benefit from HipHop, so we are releasing it as open source this evening in hope that it brings a new focus toward scaling large complex websites with PHP.

The post elaborates a bit more on what the tool is (not really a compiler, more of an optimizer) and why they decided to go this direction. There's a bit of description on how the tool works and how the transformation happens.

Stay tuned to this post around 7:30pm Pacific time for more information.

John Lim has updated his Optimizing PHP article with some new tips on caching data:

In this chapter, we explain why optimizing PHP involves many factors which are not code related, and why tuning PHP requires an understanding of how PHP performs in relation to all the other subsystems on your server, and then identifying bottlenecks caused by these subsystems and fixing them. We also cover how to tune and optimize your PHP scripts so they run even faster.

The article talks about true high performance, some of the bottlenecks that can keep you from it, tuning your Apache/IIS web server, tips on caching and some ways you can benchmark your application to figure out the best configuration for you.

Brandon Savage has a new post to his blog today with a few tips on some "micro" optimizations you can make to your PHP applications to improve performance and make for better maintainability.

Micro optimization doesn't work. So why, then, is this post called "micro optimizations that matter"? The optimizations below could be described as micro - not in the little amounts of performance improved, but in the very minute (if any) changes required to your code to make use of them. All of these optimizations are standard optimizations you should consider, and all of them will offer considerable performance enhancements.

Instead of the usual tips that might save you a millionth of a second here and there, Brandon suggests some smaller things like caching data, removing manual error logging, using a CDN and adding in an autoloader.

On the Affinity Bridge blog today there's a great post looking at the use of Xdebug and KCachegrind to pinpoint bottlenecks and possible refectoring points in your code in a bit more visual way. They use an example from their own development - a script that took around twenty minutes to run.

By reducing the number of queries, making small code optimizations, and properly indexing and keying the legacy database we managed to cut the time to 10 minutes'"still we were way off target. To get a better look at what was going on, we thought it would be great to install Xdebug and take a look at it with KCacheGrind.

They show you how to get the full setup installed (on a Ubuntu system) - the LAMP stack, Xdebug and KCacheGrind. Complete commands to install, configure and run a sample debug session are all included. Sample outputs from the KCacheGrind software are there too: code structure, execution times.

Following some of the "backlash" of Google posting their "performance tips" for PHP developers, Marco Tabini has written up a post with a suggestion of his own - stop teaching developers how to optimize their code and teach them how to code it better from the start.

In principle, I have nothing against micro-optimizations; I just think they're a waste of time - perhaps even more so because they take the focus away from the simple fact that it's a rare performance problem that is cause by the language: the problem, almost inevitably, resides either with the developer, or with an external system.

He explains that it's no so much about dropping them all together as it is starting from the beginning and teaching best practices and good use of standards and proper development practices. That's what we should be promoting, not things that might shave milliseconds off the total execution time.

On the SitePoint PHP blog today Troels Knak-Nielsen has posted some of his own thoughts about the performance tips that Google recently published for PHP.

The project includes an article on "PHP performance tips", which is bordering on being ridiculous. There are of course lots of blog posts with similar nonsense around the web, but since this is being endorsed by Google, it's fair to assume that people might take it at face value. That's unfortunate, as almost none of it is true. The PHP Team responded back with this message, wherein they refute the unfounded nonsense.

He notes that these practices aren't the best road to optimization and, depending on when they might be used, could be harmful to the development of the application. He also recommends XDebug if you really want to get to know where your application is struggling.

In response to a few tips Alex Netkachov recently posted about micro-optimization, several other developers in the PHP community have written their own responses:

• Maggie Nelson - Optimization Woes
• Sebastian Bergmann - Do Not Micro-Optimize
• Padraic Brady - Can't see the forest for the trees? Quit micro-optimising and try again
• Stefan Priebsch - The five immutable rules of optimization

Alex's tips, which have the potential to be slightly helpful, can also give a false impression that they will make a large difference in an application and could make a developer write code differently (pre-optimization) to try to use them.

Brandon Savage has posted the next article in his "Scaling Up" series, a look at reducing the amount of "drag" your application makes through its processing path and some tips to help increase its "lift" out of some common problems.

The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It's also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization.

Some of his suggestions include taking care of any sort of errors or notices (anything that could slow the script down by writing to a log), defining virtual hosts instead of making excessive use of .htaccess files and installing caching software to maximize code and information reuse.

In a quick post Jani Hartikainen take a look at some optimization tricks you can do to help get the most out of your Zend Framework/Doctrine application.

I decided to try profiling my quiz application to see if I could speed it up. Not surprisingly, biggest performance penalties came from loading classes and Doctrine's ORM magic. [...] As you may have heard, optimizing without profiling first is a bad idea, as you may think something is slow when something completely different would be better to optimize.

some of his suggestions include:

• Removing all require_once calls from the Zend Framework library
• Change the include_once_override setting if you're using APC
• Using the query cache in Doctrine
• Using the Doctrine_Table find functions rather than the Doctrine_Query objects