When and how to use transients or the object cache is a bit tricky and site-dependent. Here’s the breakdown:
-
When not using a persistent object cache (like memcached):
- Transients are stored in the database
- Objects in the object cache are only cached for the duration of the page request.
-
When using a persistent object cache (like memcached):
- Transients are stored in the object cache
- Objects in the object cache are cached in the persistent object cache and thus available across page requests.
So yes, transients can make things faster if you’re using memcached. However, if you know you’re using memcached to begin with, you could just use the object cache directly instead of mucking with a transient.
The right time to use these is thus:
For publicly released code:
-
Use a transient when you have to store anything that takes a while to generate/retrieve and which can be re-generated or re-retrieved when the transient expires. Because this may be stored in the database, don’t use it for stuff that you already have to get from the database anyway. You save very little time, even if the query is a big one with a bunch of joins and such. Rely on the database’s intelligence for this. Optimize the query instead.
-
Use the object cache to store the individual results (like, posts, or users) of large queries that might be needed often, perhaps even during the same page run.
If this is custom code for a custom site that you have (custom) control over and you know it’s using memcached, then transients and the object cache basically are the same thing, with slightly different interfaces. So you don’t really need to use transients at all, per se. wp_cache_set and wp_cache_get work quite nicely in such a situation, and without the minor amount of overhead transients add.
For multi-site, the object cache has the advantage of having “global groups”, which are specific groups (third parameter to wp_cache_set) which are considered to be global across the network of sites. You can add groups to the global grouping with wp_cache_add_global_groups().
For example, users are globally grouped in multi-site, because the users table is shared anyway. So this offers performance speedups because users loaded on one site will be put into the persistent object cache, keyed by user id, and available to all the other sites on the system in the memory cache immediately. They’re global, in other words. This can offer significant performance increases and prevent you from having to switch_to_blog a lot if you want network-wide data. For example, a most-recent-post plugin could store the latest post in the object cache with a global grouping, and then every site on the network would instantly know about it without having to search, because they’re pulling the information from the shared memory cache.
TL;DR: How you do things depends heavily on your specific use case and whether or not you’re planning on making the code available to the general public, who may not share your specific setup.