0

As a plugin developer, I strive for coding plugins that take as less server resources as possible. That's why I thought of avoiding to repeat queries to the database that are run on the same request (non-persitent).

Let's say my plugin has a function/class that needs to retrieve a setting from the options table (using the get_option WP core function). And that I know that same value will be needed by another function/class that will be run sometime after (within the same request/page load).

My question is, what would be more efficient and faster:

A) Store the value in a PHP constant
B) Store the value in a PHP global variable
C) Pass the value between calling functions
D) Use WP_Cache (cache it the first time I retrieve it and then check if a cached value exists before querying the database)
E) Do nothing and stop thinking. There's no real improvement.

OK, and what if instead of a single value, they were many, like an array of data? Would the appropriate answer be still the same? What if I'd had my settings stored in several keys and I'd like to retrieve all of them in the first place to stored them and avoid having to query/execute the get_option function as the code runs down?

4
  • options in wp are optimized and autoloaded, meaning all options are loaded on wp load time, and accessing them by get_option doesn't necessarily make a DB call. WP Object Cache caches nothing unless you have a caching plugin/driver available.
    – Ismail
    Feb 11, 2020 at 21:28
  • Thanks for bringing the "autoloaded" concept to the table @Samuel, very interesting and useful. As per Eugene's answer here, just remark that options are autoloaded only if "autoload" column is set to "yes" (which is by default). Feb 17, 2020 at 13:39
  • Not really sure that WP_Object_Cache is useless unless having a caching plugin... As per WP's doc, I'd say it is there if WP_CACHE is enabled and it is used in WP Core (e.g. get_option, as @kero pointed out). And, as the doc say "The Object Cache can be replaced by other caching mechanisms". Feb 17, 2020 at 13:48
  • Great, the source code will answer all of your questions. If you dig further into wp_cache methods you'll see how it stores cache for the active user request when no caching driver is connected.
    – Ismail
    Feb 17, 2020 at 17:54

1 Answer 1

0

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

  1. Always use the core caching mechanisms (e.g. WP_Object_Cache instead 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.

  1. Always check how WP core does things and try to work in similar ways.

  2. 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.)

2
  • 1
    Silly me not to have checked the get_option source! Thanks for you answer @kero! Feb 17, 2020 at 13:53
  • 1
    Looking into get_option source code, I see how it uses the wp_load_alloptions() function, which loads and caches all autoloaded options, as @Samuel pointed out in his comment. So, if option is configured to be autoloaded, WP will load it at the beginning of each HTTP request and keep it cached in WP_Object_Cache (no need to have a 3rd-party caching plugin for this). If the option being requested is not autoloaded, then get_option goes to check whether it is stored in WP_Object_Cache from a previous usage (within the same HTTP request). If it is, retrieves it. Else goes to query database. Feb 17, 2020 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.