[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache into WordPress

[Jacob Santos]

Lloyd Budd wrote:
> On Sun, Mar 2, 2008 at 7:31 AM, Andy Skelton <skeltoac at gmail.com> wrote:
>   
>> On Sun, Mar 2, 2008 at 1:06 AM, Computer Guru <computerguru at neosmart.net> wrote:
>>  >  I understand the difficulties of making flexible-yet-well-performing
>>  >  code. I know the tradeoffs between hard-coding stuff and having good
>>  >  page-load-times. But at the end of the day, /caching is NOT
>>  >  WordPress's biggest problem/, rather loading too many files at once,
>>  >  using way more nested loops than it should, and not skipping certain
>>  >  sections of the code when it can are what's responsible for WP's
>>  >  "legendary" fear of the /. effect.
>>
>>  These are good points. The software could make better performance
>>  decisions early in the script. Can you work your ideas into a core
>>  patch?
>>     
>
> Failing that maybe Computer Guru you would be interested in mentoring
> a student in that or a related project?
>
> It sounds similar to a couple of project ideas Matt included last
> year, but that we didn't have a student for:
> * A testing suite that measures performance of various components and
> can be regularly run against new code.
> * Currently WP loads all its code on every page, could a selective
> code loading scheme improve performance in a meaningful way?
>
> http://codex.wordpress.org/GSoC2008
>
> Thank you,
>   

I found that project to be very interesting. I would rather do the 
Controller project for the GSOC, but I'll do the Controller project 
anyway (which still doesn't mean the core team will accept it).

I've been thinking about both projects, and I have ideas for both. I 
probably don't know as much as Computer Guru on the performance topic, 
but I know some things from working with improving performance at work.

I think out of the box, WordPress should answer several issues.

1. Caching of queries
2. Support Caching sections of pages and/or whole pages and invalidation 
of those caches.
3. Browser Caching Support.

It seems to me, that #3 is only useful for those who visit a WordPress 
web site often (CMS usage) and would be very quick since it would only 
pull from the disk cache on the visitor's drive. However, it is the more 
efficient of the two. Going over it some more, I think it would have to 
have support in the query system with some overhead to tell if the page 
has been modified. I believe there are some headers which can be sent. 
It would help out with CMS projects, which have pages which don't change 
very often.

For #2, if an API existed that allowed themes to cache certain sections, 
pick and choose which parts won't change very often, then a plugin can 
take hold of that and cache just those portions based on what the theme 
says. Also, there would be an API for plugins to invalidate portions. 
Sort of like the widget API, but for caching different sections. There 
would be no built in disk caching out of the box, but caching plugins 
could be made that don't require having any files in the wp-content 
directory.

For #1, WordPress would be using the Object Cache anyway, so no big deal 
there.

That would be for the caching system and then on to the performance 
parts. By using XDebug, you can create a file which tracks the areas 
which cause the most performance hits. This might be with using the 
PHPUnit Performance test object or with creating a file which reads the 
file created by XDebug, parses it, and then outputs the problem areas. 
You could do this in a number of ways (PHP ticks for another), but I 
think creating a custom solution independent of PHPUnit would probably 
be best. This will track parts that need to be optimized.

A third option would be to support Memcache and APC, etc out of the box 
and add them to the Object Cache. They would only be enabled if the 
extension is installed, so only a small initial amount of overhead to 
check every once in a while. If they are enabled then to use them, 
instead of placing the caching in the memory. Out of the box, instead of 
using a plugin. It shouldn't add that much bloat and will allow plugins 
to focus on just disk caching, if it is needed.

Finally, going over the second part's data and optimizing and 
refactoring the problem areas will increase initial performance. What 
Computer Guru says is true, but you can only offset so much with 
optimization before you have to use some form of caching.

For the fourth project item, the only way I can think of is to use 
__autoload() function (or probably the SPL version to allow for multiple 
autoload functions to be added) or to use a Page Controller instead of 
what appears to be a Front Controller, then loading manually what is 
needed. You could also do this by having creating a build system that 
places all of the wp-includes in a single file and including that file. 
You can also have a build system which removes all comments, all 
spaces/tabs and tries to remove as many new lines as possible.

If I were to do the project, I wouldn't even mess with the fourth item, 
unless the mentor has some other idea that I don't on how to implement 
that fourth item. The first three should be enough work on implementing 
correctly, as well as optimizing core WordPress functions.

-- 

Jacob Santos

http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2

Also known as darkdragon and santosj on WP trac.