CLR Profiler

I should be creating levels but I've been distracted.  As I was running through them I kept getting stuck on the structures!  Mainly in tight door ways and similar small spaces.  This was spoiling the levels so I had to do something about it.

You may wonder what this has to do with the CLR Profiler.  Well I'll get there in a minute.

I needed to have a more detailed collision model for use during movement.  I already know my current method cannot be any more detailed because then it runs too slowly on the Xbox!

To solve that problem I have been working on a new design.  After a few optimisations to speed up loading I think the idea is workable on the Xbox.  In the process of testing on the Xbox I further got distracted by the garbage collection. 


Garbage collections appeared to be getting more frequest yet I am very careful when creating methods to avoid allocating memory.  I decided I needed to find out what I had overlooked before I got too far with a design that might make it worse!  This is what brings me on to the CLR Profiler.


I know that the CLR Profiler is the tool for finding out what allocates memory on the heap, which is what ultimately triggers the distracting garbage collection.  The trouble is I have always failed to get it to work.

I gave it another chance this weekend and at last I have useful results from it.

This is what I needed to do to get it to work for me:

Get version 4 of the CLRProfiler:

http://www.microsoft.com/en-us/download/details.aspx?id=16273
I suspect that this was the most important thing.

Then Read the Manual:

It comes with it and in the FAQ's it explains that if you are profiling a 32 bit app, even on a 64 bit system you must use the 32 bit profiler NOT the 64 bit profiler.
XNA games are all 32 bit.
Up until I read that, the profiler never started profiling!
As soon as I started using the 32 bit version it started to log results.  Easy if you read the last few pages of the manual!!!!!

The CLR Profiler comes in a compressed file and you can unzip it to anywhere.  After having done that I created a folder and copied the 32 bit binaries and DLLs in to a more convenient location.

Run As Administrator:

I created myself a shortcut and in the Advanced properties set the shortcut to Run As Administrator.  That saves a bit of time each time I run it.

Start In The Game Executable Folder:

Another important bit, for my game at least, is to set the 'Start In' folder in the shortcut to be the folder containing the executable of whatever game I need to profile. 

My game threw an exception because it could not find a folder it needed.  Changing the 'Start In' folder fixed that.

I didn't do those things immediately it took me a little while to work out what I had to do to get it to work.

Getting The Results

I can now run the CLRProfiler from the shortcut, select Start Application and then browse to the executable and run.  Play the game and when I exit I get some results.

Initially I was getting far too many results because all the level loading gets in the way.  I find the results easier to understand if I start profiling when I get well within the main game. 

Simply remove the tick from 'Profiling active' then start the game using the Start Application button.  My debug version already had a way to pause so I can swap applications.  I use the alt key to pause and bring up a test menu.  That was useful to enable me to skip to the profiler and tick the 'Profiling active' to start.  Play the game a bit then skip back and use 'Kill Application' to end.

The log files come up and...  now I have a lot of confusing data to understand.

Luckily there are several other sites I have been reading to learn what the results mean:
http://www.flatredball.com/frb/docs/index.php?title=FlatRedBallXna:Tutorials:CLR_Profiler
http://geekswithblogs.net/robp/archive/2009/03/13/speedy-c-part-4-using---and-understanding---clr.aspx

Now I can try to make some changes to my code to reduce the garbage collections.