4

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.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
Paul
  • 265
  • 1
  • 2
  • 10
  • @ruakh Yeah I do that a lot. Still working on my 5 minute rampant answer editing skillz ;) – Captain Obvlious May 18 '13 at 01:00
  • 1
    You've answered your own question with the last sentence of your first paragraph, "inside a function that may be called upwards of a 100 times during one routine". If options changing between loop iterations isn't a concern, caching the values is clearly and unquestionably the best alternative. – Ken White May 18 '13 at 01:12

2 Answers2

10

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.

syam
  • 14,701
  • 3
  • 41
  • 65
  • @KenWhite, a value that is only checked 100 times is unlikely to make a noticeable difference in program runtime. I think it's quite appropriate to ignore that part of the question, although I'd be more explicit in pointing it out. – Mark Ransom May 18 '13 at 01:24
  • @MarkRansom: First, as I said I'm not downvoting (or disagreeing). Second (and again, as I've already said), the poster explicitly said that aspect has been considered and specifically asked us to ignore it. :-) Not sure how to say it any more clearly - I *agree* that it should indeed be a concern, but it's not an answer to the question asked here. – Ken White May 18 '13 at 01:32
  • @syam I agree with you, but this specific application cannot change the options until program restart without causing serious disruption to the user, which is why I decided to do disregard changes during run time. If a user changes the options, the change is recorded in registry and doesn't take effect until the next run of the program. – Paul May 18 '13 at 01:33
  • @Paul: correct me if I'm wrong, but according to what you just said then you **need** caching (and you're exactly in the case I describe). If you use direct registry access then any change will take effect immediately, which doesn't seem to be what you want. Don't forget the user can change the registry by hand without using your interface. – syam May 18 '13 at 01:37
  • @MarkRansom 100 times is just a high average, it could theoretically be a lot more depending on what the user is doing. – Paul May 18 '13 at 01:37
  • Registry access is unlikely to access disk. I believe that most (if not all) of the registry is cached in memory by the OS; even if it did hit disk, only the first access would incur the I/O penalty, since all subsequent accesses would be served from the disk cache. But it does require a system call, since the OS does need to check security permissions, among other things, for each registry access. – Adam Rosenfield May 18 '13 at 01:41
  • @syam: OK. With your last edit, you've got an upvote from me. :-) I'm stubborn, too - I got an edit that actually addressed the question first. ;-) I'll clean up my comments, too, since they no longer apply. – Ken White May 18 '13 at 01:42
  • @syam Sorry, I think I misunderstood your comment when I first read it. Yes, that is one of the problems at the moment, which was actually one of my reasons for considering storing options in variables, but I wanted to see what people had to say about the efficiency of it before making the change. – Paul May 18 '13 at 01:44
  • @AdamRosenfield: good point. Even though *I* tend to consider cached disk access as I/O, you are right that the distinction needs to be made. – syam May 18 '13 at 01:45
8

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.]

Community
  • 1
  • 1
Captain Obvlious
  • 19,754
  • 5
  • 44
  • 74
  • Credit where it's due: +1 for the monitoring idea, which I "borrowed" even if I see it from a different angle (correctness rather than performance). ;) – syam May 18 '13 at 01:08
  • I got you on the other side of it. Correctness was definitely needing mentioning over performance. good call. – Captain Obvlious May 18 '13 at 01:11
  • Thank you for your response :-) I wish I could +1 you but it says I need a 15 reputation first. – Paul May 18 '13 at 01:28
  • @Paul don't worry someone else will probably soon upvote your question and you will have those 15 rep. ;) – syam May 18 '13 at 01:40