1

While my application works, I've found that becomes unresponsive to any commands and the CPU is 100% utilized. I've used a profiler and found that 99% of the application's time is spent in one method (which is not expected).

I'm not sure if this method is being called repeatedly or "cycles" somewhere inside (or probably dead-lock).

I didn't get much information from the profiler results:

screenshot

I don't understand why two lines close to each other have such different numbers (one 16% and the other 0.2%).

How can I figure out where the problem is?

dckrooney
  • 2,783
  • 1
  • 19
  • 27
Oleg Vazhnev
  • 21,122
  • 47
  • 154
  • 286

2 Answers2

2

For a better profiling session, use Instrumentation : this will tell you how many times a method was called. You could also use this "call hierarchy" for detecting recursive calls.

EDIT : it's available in the wizard

Launch performance wizard

Cybermaxs
  • 23,654
  • 8
  • 77
  • 108
  • i don't see such feature in VS2012. There is only "Start Perfomance Analyzing" and i can't choose if I want to use Instrumentation – Oleg Vazhnev Sep 13 '12 at 03:35
  • Sorry but it seems to be available only for VS 2012 Ultimate . In others versions, profiling is limited. VS Profiling is quite a science : you need to understand exactly how it works for efficient profiling sessions. – Cybermaxs Sep 13 '12 at 07:19
  • In your example (aka sampling session), a high percent can be caused by two differents things : many calls or poor performance of a line of code. – Cybermaxs Sep 13 '12 at 07:28
  • i have VS2012 Ultimate and still don't see "Instrumentation". As such simple line as "curPrice == moveTo" can't have poor perfomance I suppose then "many calls" is the reason. But if "curPrice == moveTo" was called many times why previos line "oldCurPrice = curPrice;" was not? – Oleg Vazhnev Sep 17 '12 at 03:55
  • @javapowered : not sure but because if+equality is more expensive than just assigning a variable. here is a link for profiling methods : http://msdn.microsoft.com/en-us/library/dd264994.aspx – Cybermaxs Sep 17 '12 at 07:22
  • @javapowered any news about this ? – Cybermaxs Sep 25 '12 at 14:09
  • no news. I just solved my problem without profiler somehow. i marking your answer as correct. – Oleg Vazhnev Oct 02 '12 at 18:56
0

You are comparing curPrice to moveTo. Is either of those a property that may run off to do a lot of code, or has one of those overloaded the comparison operators? It looks like curPrice is typically less than or equal to moveTo, so it looks like it spends 16% of the time in the first comparison, then skipped...Bid is easily tested, is > 0, and then it spends the same amount of time in the second curPrice comparison as it did in the first.

That means you could potentially save up to 32% of the time by finding a faster way to do those comparisons. That's a speedup factor of 1/(1 - .32) = 1.47, or almost 50%.

I do a lot of performance tuning, and I don't use profilers. I use this method and so do some other people. If I took 10 stack samples of this code, on average 3.2 of them would show one or the other of those comparisons on the stack, and the reason why. It wouldn't give exact percents, but that doesn't matter - they're big enough to fix.

Community
  • 1
  • 1
Mike Dunlavey
  • 38,662
  • 12
  • 86
  • 126