Been working with winkiller on optimizing serendipity (the software that runs my blog). Optimizing code is hard work. So far the results are: It is hard work finding what needs to be optimized, and it is even harder work optimizing what can be optimized.

Before I start, a few caveats:

• Most of the numbers here are pulled out of my ass. For instance, the 80/20 rule is invoked. The 8 second load time is the load time it took for s9y to execute on my slow-server.
• I don't really know much about the PHP internals, especially with regards to conditional includes (include_once for instance). All my suggestions from from my understanding of what Rasums says about conditional including.
• Most of this is just guesswork

A few of the things that I have found so far though:

• A large part of the performance problem lies in what I would call the 'sub-resources' of serendipity. The fact that loading the stylesheet and the css loads the entire S9y framework makes a big difference. Optimizing this means re-thinking the dynamic nature of the javascript and stylesheets. It would be the biggest and best optimization S9y could make, but also, the hardest. This would require a break in backwards compatibility. Not a bad thing, but not something to do lightly either. As it stands, if it takes 8 seconds to parse and execute s9y, it takes 32 seconds to actually fully load the front-page of the blog.
• Some performance could be gained in how includes are included. Mostly by removing include_once wherever possible, and using a straight include. (this also counts for conditional includes as well). This would be especially true when using an opcode cache.
• Related, would be how plugin loading and instantiation is handled. The loading of plugins could be handled at the initialization of s9y, again, in a non-conditional manner. Perhaps the best way to do this would be to keep a list of plugin files to load, and on plugin addition or removal, turn the list into a short PHP include that includes the required plugins. The speed increase may be especially significant for users with opcode caches.
• Any other optimizations would be small and numerous, but would have an overall net effect of raising the speed. Sadly, it appears (at least to my untrained eye) that 80% of the code would need to be optimized to gain a 20% speed increase.

In conclusion, the direction of S9y optimization really depends on how S9y is going to handle it sub-resources in the future. If S9y is going to be optimized further, either the sub-resources need to be modified so they do not load the entire monolith that is s9y, or, the 80% of code that I alluded to needs to be optimized, so that we can see a 60% gain. (20% gain, * 3 requests). Obviously it is better to make the sub-resource only take 1 second (for a total of 10 seconds loading the page, 8 for the main s9y, 1 for each sub-resource) rather then make everything load 2 seconds slower (for a total of 18 seconds load time).

John Lim over at PHPEverywhere has a good guide on squeezing code with xdebug.