I have made an interesting observation while tinkering with the relevance debugger today.
q: value “system” of key “DocFolderPaths” of key “Explorer” of key “CurrentVersion” of key “Windows” of key “Microsoft” of key “Software” of key “HKEY_LOCAL_MACHINE” of registry
A: C:\Documents and Settings\LocalService\My Documents
T: 0.390 ms
I: singular registry key value
q: value “system” of key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\DocFolderPaths” of registry
A: C:\Documents and Settings\LocalService\My Documents
T: 0.220 ms
I: singular registry key value
The second example is consistently almost twice as fast, even though we are ultimately querying the same key. I tried switching their order in the debugger in case the first statement was getting an advantage from some sort of caching effect but I got similar results.
This is expected because in each case you declare “key” you are looking up the specific point in the registry. Note that both are very fast (less than 1 ms) so it isn’t really a performance concern, but you are correct that it does make a minor difference.
You will see similar behavior with folders:
q: pathname of folder “desktop” of folder “ben_kus” of folder “Documents and settings” of folder “C:”
A: C:\Documents and settings\ben_kus\desktop
T: 1.048 ms
I: singular string
q: pathname of folder “C:\Documents and settings\ben_kus\desktop”
A: C:\Documents and settings\ben_kus\desktop
T: 0.418 ms
I: singular string
Generally as long as the expressions are less than 50ms, you don’t worry at all. Around 500ms-1000ms is when it starts to potentially affect the performance of the BES Client.