If you check the source code for get_option, you’ll see that it already uses wp_cache_get() and wp_cache_add() under the hood. So without looking deeper into the implementation, I would presume that two calls of get_option('foo'); would only trigger a single db call (and cache the result).
Hence, in this case E) would apply: caching is already implemented for these calls.
However, on a more general note
- Always use the core caching mechanisms (e.g.
WP_Object_Cacheinstead of some custom implementations).
You could just store it in some PHP constant/global, that is true (and probably how it will behave in a regular environment). But now I, a pro user, comes and wants to connect memcached/Redis. The existing implementations should now put the object cache in redis and take care of everything for me. Had I implemented my own caching system, I’d need to extend it myself to get it to work.
-
Always check how WP core does things and try to work in similar ways.
-
In my personal experience, one of the things that hurt performance most is
WP_Query. So cache these results if it fits your case and try to make the query quicker. (Query for less fields, don’t auto populate objects, turn some query caching/pagination off, etc.)