views:

54

answers:

3

Basically I'm wondering if I can save myself updating my code with System.Diagnostics.StopWatch, and somehow just get away with using the debugging features of VS (2008 in particular)

I.e. if I put a breakpoint before and after my method call, and then 'run' it. Is there anyway to tell how long VS was running before it stopped again? (Other than staying at the station and looking at the computer's clock of course)

If the answer is yes, please explain how.

A: 

You can use DateTime.Ticks. Rather than setting a breakpoint save the DateTime.Ticks component in a temp variable. At the point of second break point use another variable to store the DateTime.Ticks component.

Now time elapsed is Variable2 - Variable1.

There are 10,000 ticks in a millisecond.

Aseem Gautam
Isn't this what Matt is saying he's trying to avoid? He's using StopWatch, which is more accurate than this method as well...
ParmesanCodice
I guess thats a physical stopwatch he is referring to. (Other than staying at the station and looking at the computer's clock of course)
Aseem Gautam
No I think he's talking about System.Diagnostics.StopWatch
ParmesanCodice
I did mean System.Diagnostics.StopWatch
MattH
+1  A: 

As far as I know, no such a feature is built into Visual Studio.

Rather try a profiler. EQATEC Profiler is free and does exactly what you want i.e. time spent in each method and it's really easy to use....

ParmesanCodice
I've assumed the feature does not exist as no one has supported it.That being the case I created a suggestion for it! Please add your support if you think it would be useful!
MattH
I'm not sure how useful/accurate it would be? Running a program from the IDE in debug mode vs running a release build can give quite different results. Especially if you have a lot of breakpoints etc. I've had very bad IDE performance with conditional breakpoints in the past. I'm just skeptical as to how accurate such a feature would be..?
ParmesanCodice
A: 

I got all excited about replying to this post, until I actually tried it and realized that .NET projects don't support the @CLK pseudoregister trick! This sucks.

Dave