views:

763

answers:

11

Do you use a code profiler? if so, Why? What's your favorite? If not, is there a particular reason you don't?

A: 

Profiler as in bottleneck finding? Yes, but that answer won't help you because you haven't said for which language/vm etc.

Why profile code? Because sometimes you notice that too much time is spend somewhere and you don't know where without a profiler.

Armin Ronacher
+3  A: 

If you can pause code arbitrarily under the debugger, just pause/resume about 20 times. You will pause in the bottle neck the most.

Cheap, dirty and inaccurate but often works.

Warning, if for some reason your debugger won't pause in some chunks of code, this fails totally.

BCS
Yes, the "poor man's profiler". I love it.
Jay Bazuzi
Which, incidentally, is exactly how a sampling profiler works. It just samples a lot more frequently. The only thing to watch out for is that they are more likely to give false positives than instrumenting profilers.
Greg Beech
+5  A: 

If code is running too slow, and it needs to run faster, then yes I'll use a profiler to find where the bottlenecks are. I like the JetBrains dotTrace profiler because it's simple to use and gives decent results, though the new RedGate Ants profile also looks good.

Here, my first point is the most important: If the code is running too slow.

First of all you need performance goals that you want to reach, otherwise you don't know how much optimisation is enough. If you don't have any performance goals, there's not much point in using a profiler, because you could spend the time on other things like new features.

Greg Beech
+1  A: 

We use a profiler to find the slow parts of our code. We used and liked JetBrains dotTrace, but it will not profile our application under Vista x64, and we haven't found another one we like yet.

Adam Hughes
+1  A: 

For .NET, I use ANTS. In c++ I've used a few, including vTune (from Intel) and DevPartner (from Compuware). I'm not religious about any one tool, they all do the job. I use them because they're invaluable in finding performance bottlenecks. If you're not using one, you're just guessing.

omellet
+1  A: 

I used a profiler for finding the reasons for needless update/repaint calls for a graphics scene. The profiler trace has shown me the origins of the needless method calls and helped me to make the rendering much more faster!

I think this is a good example where a profiler might help you.

I used the profiler LTProf.

koschi
+2  A: 

We've used AQTime in house for .NET projects. It works fairly well for managed and unmanaged code and profiles performance,allocation, coverage, and so on. We've used it mostly for performance and allocation. In allocation, the ability to pause execution and see all the live objects has been vital for tracking down memory issues.

plinth
A: 

I have used a profiler only once, and that to answer the client's query about how many requests the system can serve given a time and memory constraint

Midhat
+2  A: 

Yes, I use a profiler. In .NET, I use dotTrace. For native code, I use Intel's VTune. I've used a number of other .NET profilers, as well as Quantify for native code. I prefer dotTrace and VTune, but YMMV-I don't think they're vastly better than the competition.

There are a couple of ways that I know of to make software fast. The first, is to write fast code in the first place, heeding your intuition and "optimizing" those things that you know will be slow. Here's the bad news: this doesn't work. There's an adage, "premature optimization is the root of all evil" (Knuth). That quote gained adage status because it's true.

The other way--the way that is actually likely to lead to fast software--is to write software that works, that is well-tested, and is modular. Then you measure to see what's fast and what's not--and, as importantly, where it matters. Next, you optimize the slow things and measure again. Your unit tests protect you from regressions. Your modular design allows you to apply targeted, isolated optimizations. Repeat 'til satisfied. The best tool for this kind of measuring is a profiler.

cero
A: 

If you are profiling using any Windows x64 Bit Version, dont wonder when your machine suddenly reboots. I evaluated intel vTune and AQTime the last weeks. Both lead to a sudden reboot, when certain options are activated. Even if debugging 32-Bit apps. With AQtime its the "user+kernel time" option. This is not a bug of the profilers (AQTime is fine) but rather a Windows problem:

http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx

This page contains the very interesting phrase:

"If the operating system detects an application or driver that patches the kernel, it generates a bug check and shuts down the system."

Tjis generates not a single word! No Bluescreen, no Entry in the Eventlog or whatever!

RED SOFT ADAIR
+1  A: 

Best profilers for each OS (IMNVHO):

Paul R
Why not VTune for Linux? Is Zoom better than VTune?
caspin
@Caspin: yes, I would say Zoom is very much better than VTune. VTune is also x86 only, whereas Zoom supports PowerPC and other CPUs in addition to x86.
Paul R