Efficiency of accessing the registry and saving user parameters in a static variable

Question

I have a program that stores some user parameters in the registry (about 5 options). Parameters are selected from the registry in the built-in function. Parameters must be checked several times at runtime. More specifically, options are checked inside a function that can be called more than 100 times in a single procedure.

My question will be more efficient: 1) Call the built-in function, which receives the parameter from the registry every time you need to check the parameter; or 2) Call the built-in function once, and then save the result in a static variable, which will then be used to test the option.

Please note that I am not interested in parameters that change at runtime, since they rarely change and do not need to take effect until the next program start.

Any feedback would be highly appreciated.

Answer 1

In terms of theoretical performance, it seems obvious that cached variables will be more efficient than re-accessing the registry (which leads to system calls and possibly even disk I / O, rather than simple memory accesses if the settings are cached). But, as @MarkRansom notes in the comments, 100 registry accesses are unlikely to greatly affect the performance of your program if your procedure is not called very often (for example, in a narrow loop).

As usual, with any performance / optimization problem: don’t worry if you really don’t know that this creates a performance problem (for example, your profiler tells you this, or you can easily prove it yourself).

---

However, there is one more problem.

You say, “I am not interested in parameters that change at runtime,” but IMHO you should: what happens if a user changes a parameter at runtime of your program? I mean, you started the calculation based on certain options that cause specific assumptions, and suddenly the parameter changes. This can easily ruin your invariants / assumptions and introduce consistency issues.

Thus, it doesn’t matter what the performance problems are, you should always cache your user settings in variables so that if they are modified by the user at runtime, your program remains consistent.

In other words, not only performance is important to me, but rather the correctness of the program .

@CaptainObvlious raises an interesting point: if you really need to update your settings whenever the user (or another application) changes them, then do it in a controlled way (as he suggests, monitoring the registry is one way) and updating your cached variables only then when it comes up. This ensures that your settings will not change in the middle of the calculation when this calculation really expects the same settings.

Answer 2

Your best option is to cache the settings in variables. When you read the value, you will receive a (one-time) download instruction and call the system API, which can perform file I / O or other time-consuming tasks to retrieve the value. If you need to deal with settings that are updated by external applications, you can always control the registry for changes - this may require additional locks for multi-threaded access. Even then, the performance will be significantly greater than when reading the registry.

[Cm. syam's answer for some considerations about the correctness of the program. This is what you should keep in mind for several settings that affect each other.]