Efficiency of registry call vs. storing user options in a static variable

Question

I have a program that stores some user options in the registry (about 5 options). The options are fetched from the registry within an inline function. The options need to be checked several times during run time. More specifically, the options are checked inside a function that may be called upwards of a 100 times during one routine.

My question is which would be more efficient: 1) Call the inline function which gets the option from registry every time the option needs to be checked; or 2) Call the inline function once and then store the result in a static variable, which will then be used to check the option.

Please note that I am not concerned with options being changed during run time as they are rarely changed and do not need to take effect until the next run of the program.

Any feedback would be highly appreciated.

Answer 1

From a theoretical performance perspective, it seems quite obvious that cached variables will be more efficient than repeated registry access (which incurs system calls and maybe even disk I/O, as opposed to mere memory accesses if the settings are cached). But as noted by @MarkRansom in the comments, 100 registry accesses are unlikely to make a big difference to your program's performance unless your routine is called very often (eg. in a tight loop).

As usual with any performance/optimization problem: you shouldn't bother unless you actually know that this poses a performance issue (eg. your profiler tells you so, or you can easily prove it yourself).

---

However, there is another issue at hand.

You say "I am not concerned with options being changed during run time" but IMHO you should: what happens if the user changes an option while your program is executing? I mean, you've started a computation based on specific options which induce specific assumptions, and suddenly the option changes. It could easily mess up your invariants/assumptions and introduce coherency problems.

So, irrelevant of the performance issues, you should always cache your user-defined settings in variables so that if they get modified by the user at runtime your program stays coherent.

In other words, to me it's not so much a performance matter but rather a program correctness matter.

@CaptainObvlious raises an interesting point: if you actually need to update your settings whenever the user (or another application) changes them, then do it in a controlled manner (as he suggests, monitoring the registry is one way) and updating your cached variables only when it is fit to do so. This ensures that your settings won't change in the middle of a computation when this computation actually expects the same settings throughout.

Answer 2

Your best option is going to be caching the settings in variables. When you read the value you'll end up with a (single) load instruction vs calling a system API which may do file I/O or other time consuming tasks to retrieve the value. If you do need to deal with settings being updated by external applications you can always monitor the registry for changes - which may require additional locks for multi-threaded access. Even then the performance will still be significantly greater than always reading the registry.

[See syam's answer for some considerations about program correctness. It's something you should keep in mind for multiple settings that affect one another.]