Performance cost of timers

[Symbai]

With recent PeriodicTimer we now have 7(👀) timer classes in .NET. It is quite obvious that even just having two totally confuses a lot of developers, see Stackoverflow question with over 600 upvotes. And even the answers aren't really clear, people seem to recommend a class based on assumption rather than knowledge. For example they recommend System.Threading.Timer over System.Timers.Timer because the last one has been removed in .NET Core 1.0 and re-adding later making them believe "Microsoft prefers System.Threading.Timer". This can be true but it also can be wrong. The official documentation gives absolut no answer. I mean there this remark section but first of all its missing PeriodicTimer and second it says nothing about performance cost.

So I have three example use cases in my program and I don't know which timer class I should use. Can someone, maybe of the .NET team, please explain which timer in which use case is the best for me?

1. Calling a web API in a very long interval of 30 minutes fetching a list of 9,000 objects
2. Calling WinAPI to react on key presses outside of my application with a very short interval of 250ms
3. Periodically check if few registry keys have been changed with a medium interval of 30 seconds

[huoyaoyuan]

I think the threading model is much more important than "performance". For interval longer than 10 seconds, I don't think there will be any noticeable difference. In the documentation page, 3 of them are associated with specific application model (WinForms/WPF/WebForm).

Though, an up-to-date description page is still desired.