views:

621

answers:

4

I am looking for a CPU profiler for .NET supporting

  • heavily threaded apps.
  • (double) quad-core CPUs.
  • sampling profiling.
  • 64 bits OS.
  • command-line API.

Currently, I am getting trouble with most .NET profilers, in particular,

  • YourKit does not seem to support command-line.
  • dotTrace 3.1 is crashing with 64 bits OS.

I haven't tried Intel VTune so far. Any enlightened suggestion?

+1  A: 

Redgate has a profiler if i remember right cant tell you if it has all you need but give it a try? :)

Petoj
It does not support command-line (as far I understand). I really need this feature to embed the profiler into a continuous integration process.
Joannes Vermorel
A: 

-- EDIT 2 --- Another possible option (but one that would require more effort) would be using NProf and just tweaking the source to strip out the GUI?

AQTime supports command line applications on 64bit OS quite well.

--- EDIT ---

AQTime also does support a command line API. It has the option to launch a project, profile, and exit automatically. I believe it would meet all of your criteria, and supports managed + native codebases.

From the AQTime help on command line:

"As you can see, using command-line arguments you can launch AQtime, load a project in it, start profiling and close AQtime once the profiling has finished. All these give you the ability to integrate AQtime in automated tests of your application. Running these tests after each application build, for instance, you can easily see if changes to the application’s code caused performance bottlenecks or inefficient use of memory."

Reed Copsey
I really need command-line support. The profiler is run withing a windows service on a remote server (through continuous integration).
Joannes Vermorel
I just checked the help - they do support a command line API :)
Reed Copsey
Yes, but AQTime does not support sampling in their profiling mode. That won't work for me unfortunately :-(
Joannes Vermorel
Sorry - just thought I'd throw that out there. It's something that's been suggested to them numerous times - I keep hoping they'll add it, because I agree, it's a limitation.
Reed Copsey
What about just using nprof and stripping the GUI out since you get the source?
Reed Copsey
I have been thinking about NProf. Yet NProf, AFAIK, has not been migrated to .NET 2.0, does not support sampling, and does not support x64 either.
Joannes Vermorel
I think it works on x64 no problem, but it does give strange results when you profile a .net2+ app. I still use it occasionally as another profile test against my .net3.5 apps, though.
Reed Copsey
A: 

What's your goal?

If you want to measure execution times and counts of routines, I guess you need a profiler.

If you want to find performance problems, so you can fix them, that is a different problem.

I'm only asking because somehow the idea got popular that they are the same.

For the latter goal, people who have tried it understand that studying a few random-time samples of the call stack of the threads is a very effective way to find performance problems.

I know Java allows you to stop all threads at the same time and dump their call stacks. I would think the .net development environment would allow the same thing.

If not, just run it under the IDE and halt one thread at a time, to see if it is wasting any cycles. If it is, you just fix it. Repeat until you don't find anything.

If you do this for all threads, then at least you know that any slowness is not due to slowness in any given thread. You could still have a problem of unnecessary message traffic. That's a little more tricky to diagnose.

Mike Dunlavey
+3  A: 

Threading tends to confuse most profilers in that they aren't sure how to count time that one thread is blocked waiting on another and time a thread is waiting around for work (if you aren't using the thread pool).

There are two profilers that you should check out in our experience: 1. Eqatech has a free profiler that does code injection for profiling. It only works down to the method level, but does work on 64 bit and can give you a sense of where your time is going. 2. The Red-Gate ANT profiler is the best we've used for drilling into line level timings which is critical if you have a scenario where threads are blocked waiting on each other for a significant part of their execution time.

That said, if you can run your tests without a user interface I highly recommend setting up some NUnit performance tests so you can quickly and easily repeat them exactly the same way each time. Doing this you can see where your time is going even with a method level profiler, propose and check individual optimizations, etc. You'll be surprised how taking time from one place just adds it to another because the threads end up waiting on each other, so having a perfectly repeatable test is very useful.

The Eqatech profiler modifies your compiled IL so whenever you re-run that IL you get a new performance tracing file, so it should fit your command line scenario. I believe ANT can work similarly.

Finally, if your application is going to be used in multiple environments I'd definitely recommend running a few performance test runs on a single processor or hyperthread only processor. When you get very aggressive about tuning for multicores you can end up adding enough overhead that you may deadlock or just be slow on small numbers of processors.

Kendall Miller