注冊表調用與在靜態變量中存儲用戶選項的效率

Question

我有一個程序，在注冊表中存儲一些用戶選項（約5個選項）。 選項是從內聯函數中的注冊表中獲取的。 在運行時需要多次檢查選項。 更具體地說，在一個例程中檢查選項可以在一個例程中向上調用100次。

我的問題是哪個更有效：1）每次需要檢查選項時，調用內聯函數從注冊表中獲取選項; 或者2）調用內聯函數一次，然后將結果存儲在靜態變量中，然后將其用於檢查選項。

請注意，我不關心在運行時更改選項，因為它們很少更改，並且在下一次運行程序之前無需生效。

任何反饋都將受到高度贊賞。

Answer 1

從理論性能的角度來看，似乎很明顯緩存變量比重復注冊表訪問更有效 （這會導致系統調用甚至是磁盤I / O，而不是僅僅在緩存設置時進行內存訪問）。 但正如@MarkRansom在評論中指出的那樣，100個注冊表訪問不太可能對您的程序性能產生很大影響，除非您經常調用例程（例如，在緊密循環中）。

與通常的任何性能/優化問題一樣：除非您確實知道這會造成性能問題（例如，您的分析器告訴您，或者您可以輕松地自己證明），否則您不應該費心。

---

但是，還有另一個問題。

你說“ 我不關心在運行期間被更改的選項 ”，但恕我直言，你應該：如果用戶在你的程序執行時更改了一個選項，會發生什么？ 我的意思是，您已經開始基於特定選項的計算，這些選項會導致特定的假設，並且突然選項會發生變化。 它可能很容易搞亂您的不變量/假設並引入一致性問題。

因此，與性能問題無關， 您應始終將用戶定義的設置緩存在變量中，這樣如果用戶在運行時修改它們，您的程序就會保持一致。

換句話說，對我來說，不僅僅是表現問題，而是程序正確性問題。

@CaptainObvlious提出了一個有趣的觀點：如果您確實需要在用戶（或其他應用程序）更改它們時更新您的設置，那么以受控方式（如他所建議，監視注冊表是一種方式）並更新緩存變量只有在適合這樣做的時候。 這可以確保在計算過程中實際需要相同的設置時，您的設置不會在計算過程中發生變化。

Answer 2

您最好的選擇是在變量中緩存設置。 當您讀取該值時，您將最終使用（單個）加載指令與調用系統API，該系統API可能會執行文件I / O或其他耗時的任務來檢索該值。 如果確實需要處理外部應用程序正在更新的設置，則可以始終監視注冊表中的更改 - 這可能需要額外的鎖以進行多線程訪問。 即便如此，性能仍將遠遠高於總是閱讀注冊表。

[有關程序正確性的一些考慮，請參閱syam的答案。 對於相互影響的多個設置，您應該記住這一點。]