I have been doing my own experiments using __rdtsc() after learning about it on HMH (thanks Casey!), and recently discovered what looks like XInputGetState() being terribly expensive to call; in the order of several milliseconds.

I googled and found this:

http://n-cpcom.googlecode.com/svn...der/input/xinput/xinputgamepad.cc

I checked to see if it was less expensive on devices that were connected, and that does indeed seem to be the case.

It would be great if someone could confirm this so it isn't just a case of my timing code being broken. This all kinds of freaks me out since I have shipped software that constantly polls (60Hz) for all 4 possible controllers, and I'm worried that I'm giving up several milliseconds of my precious 16.6 per frame for nothing...

Yes, you are right. It is know issue with XInput, that polling disconnected controllers takes significant time. You can find this mentioned in multiple places on net. Like here: https://bitbucket.org/DavidLudwig...oor-xinput-controller-performance

This suggests that it is better first to check if controller is connected with XInputGetCapabilities and use XInputGetState only if it is:
https://chromium.googlesource.com...er/gamepad/data_fetcher_win.cc#98

Thanks for the tip!

It looks however like XInputGetCapabilities() is roughly the same expense, unless I did something really stupid. I noticed that the code has some kind of "device changed hint" that was passed...

Oh, you're right. They are using WM_DEVICECHANGE window message to receive callback if there is device added or removed.

https://chromium.googlesource.com...r/system_message_window_win.cc#49
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363480