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.<\/p>\n
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<\/a> and what WordPress hopes to achieve in this program. This year, WordPress has an even-larger and more-exciting list of possible projects<\/a> than before, along with a list of the mentors available for each idea. This Google Summer of Code, I’ll be mentoring<\/a> for the WordPress projects in the one area that is closest to my heart: improving performance.<\/p>\n 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<\/em> of performance matters more than the performance itself.<\/p>\n <\/p>\n But no matter where WordPress is now in terms of high-performance, there’s always<\/em> 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<\/a>), we decided to re-write the WordPress front-end from scratch.<\/p>\n 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<\/em> 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.<\/p>\n The thing is, there’s a huge <\/em>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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading