1/n Probably this is not too well known, I know I didn't though @andrey_akinshin has a blog post about it. If your software uses a lot of Stopwatch [QueryPerformanceCounter] and we do for showing a lot of detailed measurements to our users, there are a few gotchas. That is 30%. 
2/n That measurement for me was strange, its like: How on earth could I miss 30% of the runtime cost just calling the Stopwatch Start/Stop on a core routine? It's the kind of thing that just don't escape the WTF?!?! label.
3/n I hypothesize, the only reason how that can happen is because we are somehow transitioning into kernel space. It didn't add up, at all. And when I mentioned @ayende though similarly to me.
4/n Well it turns out, it is not quite like that. There was a small little caveat about how I never found this before. Some may remember that I was having problems with measurement noise and had to beef up the rig.
https://twitter.com/federicolois/status/1371487114613944328
5/n Apparently, the @ASUS TUF Gaming X570-PLUS comes with HPET activated by default, and because that is so Windows will just decide to use it instead.
6/n What happened when we disable it? Well, we are back to normal. It is still high, but if you want really detailed metrics you need it. So if you use a lot of Stopwatch and you dont need the extra resolution of HPET on a production machine, you can just go ahead and disable it.
7/n For reference I leave you with this excellent post by @andrey_akinshin about the internals of Stopwatch. aakinshin.net/posts/stopwatc…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
