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:
Now I can try to make some changes to my code to reduce the garbage collections.