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

[Computer Guru]

On 3/2/08, Lloyd Budd <lloydomattic at gmail.com> 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,
>
> --
>  Lloyd Budd | Digital Entomologist | | Skype:foolswisdom
>  WordPress.com | WordPress.org | Automattic.com
>
> _______________________________________________
>  wp-hackers mailing list
>  wp-hackers at lists.automattic.com
>  http://lists.automattic.com/mailman/listinfo/wp-hackers
>

I don't think I can make a patch with the methods I'm using, because
they're incompatible by definition with the way WP currently does its
thing, and would also change the way WP is extended (see below).

For instance, I have functions grouped into files based on what
requests will call them and *not* what they would do. i.e.:

PerformancePress_Post.php, PerformancePress_Archive.php, etc.

.htaccess files direct requests to the appropriate files, each of
which has functions tailored to its specific category:

RewriteCond %{QUERY_STRING} ^$
RewriteRule   ^/\d+/([^/]+)/$  PerformancePress_Post.php?slug=$1
RewriteRule   ^/tag/([^/]+)/$  PerformancePress_Tags.php?tag=$1
......

(and, of course, a catch-all at the bottom to redirect to the original
WP index.php if it's not implemented)

There is some overlap between the different PP libraries, but not
much. (I chose to copy-and-paste overlapping code for that last bit of
"oomph" vs putting it in a single shared file, but I doubt it would
make a big difference if you did).

Core configuration is stored in a config file (completely
object-cached, it's an especially-good candidate for that sort of
caching since it almost never changes and almost always needs to be
called - absolutely no need to hit up the DB for this kind of stuff) -
just object-cache an array called $config[] which contains everything
you need.

Current plugin model is to have plugins include_once() files w/
functions they need - this eliminates the guess work and overheads.

The admin center of course doesn't need to touched - its performance
is of no consequence to anyone anywhere.

Lloyd, I don't have much more to add to that GSoC outline besides what
Matt's already written for performance which is generic enough to
cover everything I've just said. I guess I'll just add myself as a
second mentor for that category if that's OK.

Cheers,
Mahmoud
{CG}