[wp-hackers] GSoC Project: Performance Pre-application

Mahmoud Al-Qudsi computerguru at neosmart.net
Sat Mar 22 14:58:40 GMT 2008

I hadn't replied on-list to the original post by Jason (busy week), but he had raise some really interesting posts.

> This framework can take a form similar to a lot of the code in
> wordpress-tests/wp-testlib. My primary concern here is to make
> performance tuning relatively trivial to do, and hence can be done
> regularly, perhaps as each release's development is drawing to a
> close. I'm not sure if wordpress's development process needs this; it
> was, if anything, just a neat idea.

But you need a baseline. Assuming the goal of the project is to improve the *current* codebase and /not/ just to make sure it doesn't get any worse; then you'll need to first fix the code *then* continuously build/test/monitor its performance, no? 

> It could also handle figuring out which sections of the codebase don't
> scale well; i.e., what happens when you comment on a post with 100
> other comments? 10000 other comments?

With regards to your questions about *database*-scaling, the answer is quite simple: so long as you're using a modern RDBMS and you have decently-coded queries (i.e. no recursive nested queries, etc.) the only difference should be in the time it takes for the response to be sent to the PHP parser and for the PHP parser to circle through that many records in linear progression. I've seen it myself on my own blog, which has posts from 0 to 1000 comments.

> I believe xdebug can output files that can be visualized with
> KCachegrind; then I'd love to spend some time optimizing the most
> obvious bottlenecks. Not sure if that is worth including in the scope
> of a GSoC project?
> I think the idea of having a 'build' system that combines files
> together is worth having; opening the hundred-odd files that wordpress
> includes must be quite expensive? This is obviously a question that
> can easily be answered by testing with the framework.
More importantly: *WHY* are we opening/including all those millions of files when we only a minor fraction of them to do what we currently need? It'd be better to (RE: the codex) only include/merge files needed for each single operation and then call that (operation,file) tuple when requests are made.

> I'd love some feedback on my ideas here, what else to include, what
> I've missed, etc. This is the first time I've started working on an
> open-source project and I've been eyeing wordpress since its b2 days;
> I'm so excited to finally get involved. I'd just like to say - thank
> you for the opportunity.

Thanks for your post, it's nice to see fresh ideas and new people!

I just posted about the Performance project for WordPress GSoC 2008 on my blog; not much details, but if anyone is interested:


More information about the wp-hackers mailing list