How do you find the least optimized parts of a program?

Question

Are there any tools to give some sort of histogram of where most of the execution time of the program is spent at?

This is for a project using c++ in visual studio 2008.

Answer 1

The name you're after is a profiler. Try Find Application Bottlenecks with Visual Studio Profiler

Answer 2

You need a profiler.

Visual Studio Team edition includes a profiler (which is what you are looking for) but you may only have access to the Professional or Express editions. Take a look at these threads for alternatives:

http://stackoverflow.com/questions/26663/whats-your-favorite-profiling-tool-for-c http://stackoverflow.com/questions/153559/what-are-some-good-profilers-for-native-c-on-windows

You really shouldn't optimize ANY parts of your application until you've measured how long they take to run. Otherwise you may be directing effort in the wrong place, and you may be making things worse, not better.

Answer 3

I have used a profiler called "AQ Time" which gives every detail you want to know about about the performance of your code. It's not free though..

Answer 4

So now that you know you need a profiler, you might not have the Visual Studio one, so Very Sleepy might be of help.

Answer 5

You could get a histogram of the program counter, but it is practically useless unless you are doing something dumb like spending time in a bubble sort of a big array of ints or doubles.

If you do something as simple as a bubble sort of an array of strings, the PC histogram will only tell you that you have a hotspot in the string compare routine. That's not much help, is it?

I know you wouldn't do such a bubble sort, but just for fun, let's assume you did, and it was taking 90% of your time. (i.e. if you fixed it, it could go up to 10 times faster.)

It's actually a very easy thing to find, because if you just hit the pause button in the debugger, you will almost certainly see that it stops in the string compare routine. Then if you look up the stack one level, you will be looking directly at the bubble sort loop which is your bug. If you're not sure you've really spotted the problem, just pause it several times. The number of times you see the problem tells you how costly it is.

Any line of code that appears on the call stack on multiple pauses, is something that is begging you to fix it. Some you can't, like "call _main", but if you can you will get a good speedup, guaranteed.

Then do it again, and again.

When you run out of things you can fix, then you've really tuned the program within an inch of its life.

It's that simple.

---

You could also use the profiler in Visual Studio. It is a nice tool but be aware of these shortcomings:

• Confusing you with "exclusive time", which if you concentrate on line-level information, is almost meaningless.

• If your program is wasting time doing I/O, it won't see that, because when it stops to do I/O, the samples stop, unless you use instrumentation.

• But if you use instrumentation, you won't get line-level information, only function-level. That's OK if your functions are all small.

• Confusing you with the "call tree". What matters for a line of code is how many stack samples it is on. If it is in many branches of the call tree, the call tree won't show you what it really costs.

• If it tells you a line is costly, it cannot tell you why. For that you want to see as much state information on each sample as you need, rather than just summaries.

• It's hard to tell it when you want to do samples, and when not. You want it to sample when you're waiting for the app, not when it's waiting for you.