[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/24/2012 12:38 PM, Otto wrote:
> Page caching would indeed use the advanced-cache.php drop-in.
> WP-Super-cache does exactly that. Using transients there would be
> highly difficult, however I'm not sure that you'd want to,
> realistically. Transients are essentially wrappers around database or
> object cache calls. Storage of whole-page caching methods is capable
> of being done more directly, and much faster, without the overhead
> transients and the object cache bring to the table. Either you store
> the page cache in a way that bypasses the need for PHP to execute at
> all (super-cache) or you store the page directly in an external memory
> system, where the WP_Object_Cache overhead is not helpful to you.

Ok... so now you'll admit that the Transients API has high overhead, is
difficult to use, and is in-appropriate for page or fragment caching.
You also admit that the dropins are "hacky as heck".

However, you'll still tell me that's what I should use when I so much as
suggest that WP_Object_Cache could be expanded (in a 100% backwards
compatible way) to support persistent cache backends in core like it
used to, but done the right way this time.

I didn't honestly think I had to actually submit a patch yet just to
explain what I was proposing since nearly everyone else implements a
flexible caching system with multiple backends nearly the same way, and
the way I'm proposing. How about some examples then?

In the category of PHP applications that aren't built on frameworks
since this is where WordPress falls in:

1. MediaWiki:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=tree;f=includes/objectcache
2. phpBB:
https://github.com/phpbb/phpbb3/tree/develop/phpBB/includes/cache/driver
3. Gallery:
https://github.com/gallery/gallery3/tree/master/system/libraries/drivers/Cache
4. phpMyAdmin used to use phpExcel's cache library:
https://github.com/PHPOffice/PHPExcel/tree/develop/Classes/PHPExcel/CachedObjectStorage

All of them are mostly designed the same way object cache APIs are
designed on nearly all the frameworks, let's jump to those:

4. CakePHP: https://github.com/cakephp/cakephp/tree/master/lib/Cake/Cache
5. Symfony: http://www.symfony-project.org/api/1_4/sfCache and
https://github.com/symfony/symfony/tree/master/src/Symfony/Component/HttpKernel/Profiler
6. Kohana: https://github.com/kohana/cache/tree/3.2/master/classes/cache
7. CodeIgniter:
https://github.com/EllisLab/CodeIgniter/tree/develop/system/libraries/Cache/drivers

(Zend purposely left off the list, but it does multiple persistent
object cache backends the same way too - just very different frontend)

This isn't even limited to PHP. Even though Python and Ruby web
application processes handle multiple requests, they still implement
object cache APIs the same way:

8. Django:
https://github.com/django/django/tree/master/django/core/cache/backends
9. Beaker (a python cache/session library):
https://bitbucket.org/bbangert/beaker/src/d1757ad53763/beaker/
10. Ruby on Rails:
https://github.com/rails/rails/tree/master/activesupport/lib/active_support/cache

MediaWiki doesn't even tell everyone they should write object cache
implementations in extensions. They provide over a dozen persistent
object cache backends to choose from including multiple memcache backends.

How about this...

What if the Transients API was converted over to a WP_Object_Cache
backend, and used as the default fallback instead of the file backend if
none of the accelerators are available (APC/XCache/WinCache)? The
current API can still continue to fire off the same filters (and will
just make calls into wp_cache_get/set()) and new code can feel fine
about using wp_cache_get() with an expiration again, and page/fragment
caching plugins have a persistent object cache to use before the hooks
system is initialized. The transients API is really just a DB object
cache backend anyway (but with filters).

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com