Profiling with Stopwatch

re: Profiling with Stopwatch

Dominik Dalek — Thu, 09 Jul 2009 02:54:26 GMT

What about the perf impact of calling new ProfileMarker() every time? For smaller methods that are executed often in the code this can IMO significantly skew the results (especially on Zune).

re: Profiling with Stopwatch

ShawnHargreaves — Thu, 09 Jul 2009 05:21:02 GMT

> What about the perf impact of calling new ProfileMarker() every time?

Allocating a 4 byte value type is pretty much insignificant unless the code you are trying profile is incredibly quick (in which case it most likely isn't your hotspot in any case :-)

re: Profiling with Stopwatch

gamedboy — Thu, 09 Jul 2009 05:40:04 GMT

hi, correct me if I am wrong.

Since ProfileMarker implement IDisposable,

there will be a boxing of ProfileMarker when

Dispose is called?

re: Profiling with Stopwatch

ShawnHargreaves — Thu, 09 Jul 2009 17:53:45 GMT

> Since ProfileMarker implement IDisposable, there will be a boxing of ProfileMarker when Dispose is called?

No. ProfileMarker is a value type, and is never used polymorphically, so there is no heap allocation or boxing.

re: Profiling with Stopwatch

ShadowChaser — Mon, 13 Jul 2009 20:39:30 GMT

Most .NET profilers I've used tend to cause the .NET compiler/JITer (or both) to cause issues with optimizations.

The main issue is structs - given that a game in a tight loop is sensitive to objects created on the heap (later GCed), the use of structs is fairly important.

I noticed that the XNA framework uses "ref structs" in quite a few places for input only parameters - going against the "spirit" and design guidelines of .NET. Why? .NET doesn't optimize structs properly in the debugger. The same goes with profilers.

I had "ref structs" all over my game and fairly unreadable code littered everywhere as a result. Ripped them all out and replaced them with the "slower" normal structs. No difference in release mode, but the second I attach a profiler the game slows down by 50% and it shows I'm spending all my time copying structs around on every function call.

In other words, 99% of the time I end up chasing "Heisenbugs" when profiling XNA games. I really wish the struct issue would be fixed in debug mode, but it's probably for some arcane debugger reason deep in the CLR :(

The best thing I ever did was follow my guts, use Stopwatch, stop profiling in all but specific cases, and use structs *normally* :) The CLR figures out the best thing to do during Compile time/JIT anyways.

re: Profiling with Stopwatch

ShawnHargreaves — Tue, 14 Jul 2009 02:50:39 GMT

@ShadowChaser: that sounds like you were using an instrumented profiler (which hooks into the code generation and can alter performance characteristics in a similar way to when a debugger is attached) rather than a sampling profiler (which does slightly slow execution due to the overhead of taking the samples, but is a fixed cost that will not slow one part of your program more than others).

There is a time and place when instrumented profiling makes sense, but I most often find sampling profilers to be a better starting point.

Passing large value types by reference can be a very worthwhile optimization when applied in the right places, but it's only worth doing this in critical hotspot code.

re: Profiling with Stopwatch

HerrUppoHoppa — Tue, 14 Jul 2009 10:45:42 GMT

The only problem I have with this is that the profilers are auto listed on construction but never removed from the list.

If this were C++ I would just remove it in the destructor, simple and consistent. But since this is managed code and people seem to shun destructors here, how could this be resolved in a good way?

Regards

Pontus Birgersson

re: Profiling with Stopwatch

ShawnHargreaves — Tue, 14 Jul 2009 18:17:58 GMT

@HerrUppoHoppa: the standard pattern in .NET is for things that require deterministic cleanup to implememt IDisposable and do whatever cleanup they need in their Dispose method.

I didn't bother with that since I never needed to remove profiler instances.

re: Profiling with Stopwatch

ShadowChaser — Wed, 15 Jul 2009 18:47:53 GMT

@ShawnHargreaves: that makes a lot of sense - all of my profiling had been done using instrumented profilers. Thanks for the great tip - I'll definitely look into sampling profilers a bit more.