For those of you that haven’t yet heard, WordPress is once-more taking part in the Google Summer of Code. Google Summer of Code 2008 is a Google-sponsored program where college students are encouraged to contribute to their favorite open-source projects for a summer, and in exchange both they and their mentors receive some monetary compensation/motivation for their efforts.
I really don’t need to go into details about this much, since Lloyd Budd has done such a good job explaining what it is and what WordPress hopes to achieve in this program. This year, WordPress has an even-larger and more-exciting list of possible projects than before, along with a list of the mentors available for each idea. This Google Summer of Code, I’ll be mentoring for the WordPress projects in the one area that is closest to my heart: improving performance.
It would be unfair to say that WordPress is slow or an inadequately-performing blogging engine, because that’s not really true. "Performance," more than any other software characteristic or trait, is a very relative and subjective index. It depends on thousands of different factors, it has dozens of different baselines, and most confusingly of all, sometimes the perception of performance matters more than the performance itself.
But no matter where WordPress is now in terms of high-performance, there’s always room for improvement. Late last year, disappointed in this very blog’s less-than-stellar showing during the many Slashdot and Digg appearances (even on a damn-decent dedicated server), we decided to re-write the WordPress front-end from scratch.
You’re looking at the result now: the homepage and individual posts are powered by PerformancePress, our in-house re-write of the WordPress page-displaying code. The NeoSmart Files is still running WordPress, just behind the covers. The procedure we followed in developing PerformancePress was simple: only load what you need, don’t waste CPU cycles if you don’t have to, minimize SQL queries wherever possible, don’t loop when you can avoid it, and a number of other load-reducing principles.
The thing is, there’s a huge difference between in-house code and software that’s been "generically-developed" for use by the masses. While we could make assumptions about our own use of the blogging system, the WordPress project doesn’t have that privilege. There is no cutting-corners or jumping to conclusions on a for-redistribution project. Flexibility usually comes at the cost of optimization; and the net result can be more than a little tricky to understand.
These are some of the same reasons we cannot just "release" the current PerformancePress code we’re using here – it wouldn’t last 10 minutes in the real world. But hopefully this Google Summer of Code we will have a chance to bring out in WordPress the best of both worlds. PerformancePress is most likely a dead-end; but it’s been an invaluable experience in realizing how to create the most resource-efficient, well-scaling webapps; and hopefully we can take that to the next level this summer.