chrismingay.co.uk Me and my games

Monkey, XNA and CLR Profiling

Since the weekend I've wanted to do some CLR profiling on the code generated by Monkey and tonight I finally managed to do it. I've never done CLR profiling before, hell, I don't even know what it stands for and until the first the first time I started making Ninjah in XNA I didn't even consider needing to be careful about memory allocations so this is all new to me.

On Monday I concluded that I couldn't realistically do much more with my coding so it must be something Monkey is doing to cause a hell of a lot of garbage collection. All of the blog posts I could find mentioned CLR Profiling so with the help of THIS and THIS I did it and got the following...

Cause of allocation from DrawImage

Cause of memory allocation for DrawText

The bars between the blocks indicate the amount of memory allocation that has occurred through a function, method or whatever it is.  In the first instance, you can see that the DrawImage function I call is calling DrawSurface which is allocating lots of memory to Vector2's and Vector3's. In the second example you can see that the DrawText function I call, is calling DrawImage which is calling DrawSurface2 which is again allocating lots of memory to Vector2's and Vector3's.  Such a frequently used function should not be causing so much allocation. The PC based GC can handle this  (which explains why I didn't run into any issues early on), but the Xbox based GC really cannot and to quote THIS ...

- GC on Windows is not a good thing and you should try to avoid generating garbage where reasonably convenient.
- GC on Xbox is a very bad thing, and if your game is intended for Xbox 360 you should go out of your way to avoid it everywhere possible.

DrawText I can do without but Blitz really need to fix DrawImage to make it usable for Xbox 360 games.

Monkey -> Xbox = :(

I am developing Ninjah primarily for Xbox 360 via Xbox Live Indie Games. Until Friday I had been developing this on my PC and making the assumption "well if it runs on my old laptop it will definetly run on a current gen games console like the Xbox 360". This has turned out to be quite a naive assumption because Ninjah runs badly on the Xbox, quiet badly considering how simple to code actually is.

I have spent most of the past weekend trying to find what was causing the slow down and to start with I was confident that the issue related to the manipulation and presentation of string objects. I removed these items from the main menu and indeed, the stuttering I had been experiencing stopped. Running the Remote Performance Monitor indicated that there was now very little garbage collection happening. "Yay! " I thought to myself, "I have solved it". While inconvinient, it certainly wasn't a show stopper. All I needed to do was replace the reletively small number of strings in the game with images of text (e.g. the tutorial text, level names etc). Before starting this, I thought I'd check the actual game area again and unfortunately the stutter was still occurring due to the GC having to work extremely hard still.... joy.

Now, when I had been making Ninjah directly in XNA, I had run across a problem where using lists to store instances of classes was also causing stuttering (at the time I didn't know it was due to garbage collection, but in retrospect, it seems pretty obvious). The solutions mentioned on forums stated to use an object pool. An object pool can be as simple as having a predefined amount of instances stored within an array. These objects are only drawn/updated when they are active and when a "create" call is made, the array is searched through for an inactive instance which is then activated and manipulated to appear as a brand new instance.

Basically, at the start of an app I create 500 new particles in an array and from this point onwards no additional particles are ever created, this pool of 500 is recycled as required. This is great because it leads to very little additional memory allocation which in turn causes garbage collection. For Ninjah via Monkey, I had been using lists because I assumed they wouldn't cause these issues, however, I now believed that this was causing the GC stutter.

So... I figured that to fix the problem I would go through the irritating process of replacing all list code with array based pool code. All in all, this actually went much quicker than expected and I was looking forward to seeing Ninjah running at a constant 60fps on the Xbox. It didn't and it was still stuttering. I went as far as having just a simple level drawn on screen with no game logic being run and the stuttering still occurred. I removed all currently unused graphics from the build, no change. I removed all sounds from the build, the same. I even went as far as to remove all instances of a Local variable being created and it made no difference at all.

I felt very much like I was sat on the floor with a crowbar in hand, out of breath, surrounded by the broken parts of my once functioning game; all in all a bit gutting. At this stage I made another assumption (I've really got to stop doing this), that deep down I had coded something badly, so for peace of mind more than anything I decided to make a very simple app from scratch that did nothing but draw a set amount of particles.

I am in two minds to see that this too is causing the garbage collection to skyrocket once a certain number of draw items is hit, this lead me to believe that there are issues above my coding (relating to the way Monkey transcodes source to XNA/C# code). The good part thinks "well, it wasn't me afterall, there was nothing I could have done differently". The bad part things "I have absolutely no control or ability to fix this problem".

I briefly entertained the idea of saving each level to an individual image file to reduce the number of draws required, but I shouldn't have too and really, I just think that the issue will show up later down the line in another area. Drawing ~200 items a frame is a tiny amount compared to what should be possible.

As it stands then, I am pretty much at the mercy of Mark the developer of Monkey. I can continue work on Ninjah on the assumption that one day the transcoding will be Xbox friendly, but if that doesn't happen any time soon I will have to consider releasing it on PC first and/or working on it directly in XNA (something I'd rather not do because the Monkey language seems much easier to me).