some parts of my program are way slow. and I was wondering if there is tool that i can use and for example it can tell me ok running methodA() took 100ms , etc ...or so useful info similar to that.
-
3It's called a [Profiler](http://stackoverflow.com/search?q=[c%23]+profiler). – dtb Sep 22 '10 at 20:46
-
1What you are looking for is called a profiler. – GrandmasterB Sep 22 '10 at 20:46
-
2possible duplicate of [What Are Some Good .NET Profilers?](http://stackoverflow.com/questions/3927/what-are-some-good-net-profilers) – dtb Sep 22 '10 at 20:47
4 Answers
If you are using Visual Studio Team System there is a builtin profiler in 'Performance Tools'. There is a ton of useful background on this at this blog.
I've found this extremely useful in identifying the 20% of my code that runs 80% of the time, and hence what I should worry about optimizing.
Another simple technique that can be surprisingly effective is to run your release code in the debugger, and interrupt it a few times (10 or so can be enough) while it's in the 'busy' state that you are trying to diagnose. You may find recurring callstack info that directs you to the general area of concern. Again, the 80/20 rule in effect.

- 21,988
- 13
- 81
- 109

- 53,498
- 9
- 91
- 140
-
1+1 I've been using that interrupt method since before profilers were conceived of. I was mystified that so few people knew it. I would say it actually pinpoints the area of concern, and the 80/20 rule is more like 99.9/0.1 – Mike Dunlavey Sep 23 '10 at 01:58
-
-
@Mike Dunlavey - do you have a better one? I will edit in if so. Thanks – Steve Townsend Sep 23 '10 at 13:00
-
References on this are alomst non-existent for some reason: http://stackoverflow.com/questions/3743504/any-references-on-dynamic-code-analysis/3745797#3745797 – Mike Dunlavey Sep 23 '10 at 14:36
-
-
I just emailed you a copy. I'm afraid you'll find it rather dry. – Mike Dunlavey Sep 23 '10 at 15:25
The System.Diagnostics namespace offers a helpful class called Stopwatch, which can be used to time parts of your code (think of it as a "poor man's profiler").
This is how you would use it:
Stopwatch stopwatch = new Stopwatch();
stopwatch.Start(); // Start timing
// This is what we want to time
DoSomethingWeSuspectIsSlow();
stopwatch.Stop();
Console.WriteLine("It took {0} ms.", stopwatch.ElapsedMilliseconds);

- 9,299
- 2
- 28
- 35
-
3or, create a class that implements idisposable, which starts the timer on contruction, stops and writes on dispose. Then you can time any block of code by wrapping it with a using statement! – John Gardner Sep 22 '10 at 21:02
-
2Also make sure that the method has been invoked at least once before timing it, so that you don't measure the time for JIT-compilation. – Fredrik Mörk Sep 22 '10 at 21:05
-
@John Gardner - your construct is also v useful for getting perf timings out of a running Prod system. Accumulate the timings for parts of the workitem with a tag that identifies them, and dump at the end of the workitem. – Steve Townsend Sep 22 '10 at 21:05
See our SD C# Profiler. It can provide function timings of the function by itself and/or all of its callees.

- 93,541
- 22
- 172
- 341