[wp-hackers] Caching as part of the core

[Mike Schinkel]

Well said.

-Mike

On Jul 23, 2012, at 9:31 PM, Bryan Petty wrote:

> On 07/23/2012 12:25 PM, Michael Van Winkle wrote:
>> However, I'm not sure I understand why the existing object cache is 
>> insufficient for delivering that fragment. Can we get more specific
>> about what the failure of the current object caching api is? I think
>> a MUCH bigger issue is theme/plugin developers generally lack of
>> awareness and/or concern for caching and performance.
> 
> Personally, I believe the failure is mainly in the fact that the
> existing object cache isn't persistent. A cache that doesn't have the
> ability to persist across requests is really just a glorified static
> class variable / global variable. It doesn't actually provide anything
> helpful that you couldn't already do without it.
> 
> Of course fixing that does absolutely require an outside service such as
> memcache/XCache/APC, or just fall back on file. There's two main
> arguments I keep seeing against expanding the existing object cache to
> support these:
> 
> 1. Most shared hosting providers don't supply any of those services.
> 2. This should be implemented by plugins (and is currently).
> 
> At Bluehost, even though we don't offer memcache directly, a number of
> customers have still compiled and run it themselves on our servers
> anyway (and we do enable the PHP memcache extension). On the other hand
> though, nearly every shared hosting provider does support file write
> permissions, so at the very least, the file cache backend would work out
> of the box on 99% of shared hosting accounts.
> 
> Putting that aside, it's possible to not only enable support for all of
> the backends mentioned above in core WP, but to do so in a completely
> backwards compatible way with the existing object cache, *and* also do
> so without adding a single extra option to the installer *or* the
> administration panel.
> 
> Those on shared hosting providers without support for any of those
> backends (including file cache, assuming no write permissions)
> wouldn't even notice support for this was added. And for those that do
> support it, it could either be automatically configured during install
> (though I wouldn't recommend that - beyond enabling the file cache at
> least), or it could be a couple incredibly simple options in
> wp-config.php (as opposed to looking for and installing some possibly
> defective/dangerous 3rd party plugin/drop-in).
> 
> All web application frameworks provide this API exactly as I described
> here and they do it because most web applications need it, and while
> WordPress isn't trying to be a web application framework, it's not built
> on top of one, so it has to provide it's own. I do actually believe that
> this doesn't belong in WordPress, but that's only because it belongs in
> a web framework. It's not like WordPress will ever be built on one
> though, so there's really not much choice than to add it.
> 
> As for implementing it in a plugin, is there really more than one way to
> write an API around a cache engine? There really isn't, they're all the
> same, they just store the objects in different ways. So what is the
> point of it even being a 3rd party drop-in or plugin?
> 
> To get back to your concern that the main issue is a lack of awareness
> for caching or performance, I think part of that also has to do with the
> fact that the existing object cache is barely helpful in the first place
> because it's not persistent. When plugin authors know they can cache
> data for longer than a single request (and that it will work on nearly
> all WP installations by default without requiring additional plugins),
> they'll be much more likely to make use of the caching engine since it
> will actually make way more of a difference.
> 
> -- 
> Bryan Petty
> WordPress Developer
> bpetty at bluehost.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers