Are performance counters the right tool for my job? If so, how do I use them?

Question

I've been asked how to find out how much memory and CPU my program is using, and I've been referred to Performance Counters. However, when I look at the documentation it starts off by telling me about providing consumer data by creating a manifest for my application, and my eyes glaze over. It's nice that such a general-purpose tool is there, I suppose, but all I wanted was a set of functions that would tell me how much memory and CPU my program is using.

Are performance counters the right tool for my job? If so, how do I use them? I really don't want to have to set up anything outside my C# application.

NOTE: I'm not looking for a third-party profiling app, I need to have the memory and CPU data displayed by my app.

UPDATE: I've removed time in functions, as it seemed to be confusing the matter.

Answer 1

You can use perfmon out of the box to monitor CPU, Memory and Disk usage as well as many .NET specific performance counters. perfmon comes with windows.

The eye-glazer is required only if you want to write your own perfmon, or if you want to offer your own performance counters. The latter would be interesting only if your users would need to monitor this value (e.g. you are developing a server application and your users need to make sure there are no more than 10% of connections rejected due to invalid moon phase).

For determining how much time you spend in certain functions, use a profiler.

---

The Performance Counter API would allow you to monitor the data together with existing performance counters (which might tell you e.g. that function Foo gets very slow every night after 11 because some other process is thrashing the disk), and the monitor can run as a service and produce log files for later analysis.

You must figure out whether these benefits are worth the additional trouble of performance counters, or if you are better off with a logging system.

There are quite some samples out there that might make it easier for you. However, it still pays to understand the architecture and "official" terminology. Typically, MS API's do require a lot of reading and looking for some good wrapper code, that doesn't mean they are always painful.