Psychic Perf Analysis, or "RegFlushKey actually DOES flush the registry key"
One of Raymond's more endearing features is what he calls "Psychic Debugging", it even made his wikipedia entry (wow, he even has a wikipedia entry, complete with picture :))
There's a variant of Psychic Debugging called "Psychic Perf Analysis". It works like this:
I get an IM from one of Ryan, one of the perf guys.
Ryan: "Hey Larry, we just found a great perf bug that caused a 3 second slowdown in Windows boot time"
Me: "Let me guess, they were calling RegFlushKey in a service startup path."
<long pause>
Ryan: "Who told you?"
One of the things people don't realize about RegFlushKey is that it actually flushes the data that backs the registry key (doh!). Well, flushing the data means that you need to write it to disk, and the semantics of RegFlushKey ensure that the data's actually been committed - in other words, the RegFlushKey API is going to block until all the disk writes needed to ensure that the data backing the key is physically on the disk. This can take hundreds and hundreds of milliseconds.
In Ryan's case, it was complicated because the service was calling RegFlushKey from a DllMain function (Doh!) which held the loader lock, which meant that all the other services in that process were blocked, and there were other services that depended on those services, and... You get the picture, it REALLY wasn't pretty.
The documentation for RegFlushKey explicitly says that "In general, RegFlushKey rarely, if ever, need be used", and it's right.
Why did I know that this was a problem? Well, when we first deployed the new audio stack into Vista, we were blocked from RI'ing into winmain because the audio service degraded the boot time of Windows by 3/4 of a second (yes, we measure boot time performance to the millisecond, and changes that degrade the system boot performance aren't allowed in). When I looked at the perf logs of the boot process, I noticed a significant number of writes occurring during the start of the audiosrv service. I chased it down further, and realized that the writes correlated almost perfectly with some code that was modifying the registry. I dug deeper and discovered a call to RegFlushKey that we had mistakenly added. Removing the call to RegFlushKey fixed the problem.
Comments
Anonymous
March 02, 2006
Looking at the Wikipedia pic:
http://upload.wikimedia.org/wikipedia/en/6/6b/Raymond_Chen%2C_PDC05.jpg
how many hands does Raymond have??!Anonymous
March 02, 2006
Mike: The answer is 42.Anonymous
March 02, 2006
Idunno, but they're withered. http://blogs.msdn.com/oldnewthing/archive/2005/09/23/473270.aspx
VornAnonymous
March 02, 2006
How do RegFlushKey calls end up in startup code for a service?
Do you know what the purpose of putting them there was? The only use I can imagine for it is some sort of transactions, which would not likely have any business in startup code.Anonymous
March 02, 2006
Larry, why did the developers think to call RegFlushKey in the first place? This isn't meant as a facetous question: unless the registry is being used for logging (which would seem inappropriate) or a complex scheme of transactionality is being implemented, I can't think of a reason to do so. In the latter case, it would seem like there's no solution that doesn't involve committing.
Assuming that this wasn't redundant code, and that neither of the conditions above is true, I think this gets to the heart of my problem understanding the registry. I don't understand how views of the registry are synchronised between applications. Consequently, I've always wished there was some kind of 'sharing mode' on registry keys, the same as for files. As things stand, the code I write relies on RegSetValue appearing atomic and goes to extreme measures to avoid relying on results of previous calls in order to read values, etc. It's tricky, and there aren't many hints in MSDN about doing it properly.Anonymous
March 03, 2006
On Exchange support late at night bouts of "Psychic Troubleshooting" were common.
I believe the combo of coffee, Mountain Dew, and those instant ramon noodles brings out the latent Psychic powers in even the most feeble minded "C dash".Anonymous
March 03, 2006
Gabe/James, the RegFlushKey was added for the same reason that we accidentally added it into the audio stack - to ensure that the writes were flushed. It's just that there really isn't normally a need to ensure that all the writes are flushed.
And how did it get into the startup code for a service? I don't know, it was actually in the DllMain of a dependant DLL, it's entirely possible that that DLL was owned by an unrelated team that didn't realize that their code was called by a service.Anonymous
March 07, 2006
> wow, he even has a wikipedia entry, complete with picture
But you're blog is linked to from at least one entry... http://en.wikipedia.org/wiki/Dancing_pigs_%28computer_security%29Anonymous
April 04, 2008
The comment has been removedAnonymous
April 06, 2008
PingBack from http://www.b-spot.se/designing-for-add-on-performance/Anonymous
May 01, 2008
PingBack from http://en.luga.name/?p=58Anonymous
May 01, 2008
PingBack from http://en.luga.name/?p=60Anonymous
May 01, 2008
PingBack from http://en.luga.name/?p=64Anonymous
March 17, 2009
PingBack from http://vistahome.org/2009/03/17/ie8-designing-for-add-on-performance-vista-home/Anonymous
March 19, 2009
  최근 Internet Explorer 8 Beta 1 출시를 위해 개발중인 IE 팀은 성능에 심혈을 기울이고 있습니다. IE  향상을 위한 노력의 일환으로 실행한Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=10209Anonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=17956Anonymous
June 02, 2009
PingBack from http://woodtvstand.info/story.php?id=51397Anonymous
June 09, 2009
PingBack from http://menopausereliefsite.info/story.php?id=1229
