Profiling is great! ... What does it do?

The profiler has been gone from Visual Studio for awhile. I think... 6.0? Or maybe even 5.0 was the last incarnation. The core idea is to provide a tool to find those parts of your application that are preventing it from meeting performance goals, and to help document where the critical time being spent in the application.

As such, I would like anyone reading this to leave a comment and let me know what you expect a profiler to be, and what you expect it to do.

Should it only tell you about your CPU so you can find bad algorithms? Should it integrate other system information? And if so, what? Thread interactions? Perfmon Data? System event tracing logs? What needs to correlate? What doesn't. Has to work for .Net Code? Native code? Mixed? Asp.Net? Code running on my local machine? Code running in a deployed environment?

Obviously the answer is: Do all of it, all the time. But let's be realistic -> What information needs to be surfaced quickly and easily for you to make sure your projects have the best performance they can, and what would just be 'nice to have'.

[jrohde]