Today though, I (re)wrote an object pool class.

Garbage collections are expensive on the compact CLR, they occur whenever 1MB of garbage is created, and cause noticeable stutter in the game when they happen. For this reason, I simply try not to generate any garbage.

Why we can’t just choose to have collections occur every 16MB or something, I don’t know.

I’ve written custom pools in various places in this project, because creating an efficient generic pool is tricky. Have a look at swampthingtom’s generic object pool. It uses a struct as a container for each pooled item and can only pool types that meet the new() constraint (public parameterless constructor, and no abstract classes allowed).

Having to write a pool for every type though is slowing me down, so I spent some time today thinking about a good design for a generic object pool.

Giving up abstract classes (which is what swampthingtom does with his pool) is going a little too far for me. Also, a significant performance cost is associated with the use of that pool, which makes it less than ideal if you are using it to allocate hundreds of objects or more.

Here’s another approach, which is minimalist, and still uses the new() constraint. This pool is clearly faster, but offers no way to iterate over over the collection of active pooled objects, and again, no abstract classes or constructors with parameters allowed. It’s also basically just an unsafe version of Stack

So I wrote a pool that partitions an array into two parts, the first part for live objects, the second for dead objects. Then I effectively do what the compact CLR does with dead objects — sweep across the dead objects once in a while, and compact them into the second part of the array. As for object initialization, I pass the pool a Func delegate that does the initialization. Delegates are a little slow, but in this case they are called rarely — in fact, they should be called never, if I pick the right pool sizes. The code is barely tested so far and might benefit from another small optimization or two, but I’ll be sure to post it soonish. As usual, I’m also not fond of the idea of posting good code this far from the competition deadline.

By the way, I fought with stackoverflow to try to get some discussion going about ways to iterate over the pool without generating garbage. Most people did not want to hear about avoiding garbage creation. Eventually Eric Lippert came to the rescue and defended my question.

The bloom filter takes the brightest parts of the image, blurs them, and mixes the result back into the scene. This makes lights glow, softens bright edges, and generally makes things look more natural.

Since there’s very little light you can’t notice the bloom so much, although it’s very obvious on the bottom center bar indicator. The rest of the HUD does not have the bloom applied to it.

The blue sky effect resembles an aurora somewhat, and is animated. It’s obviously more interesting to see in motion than in this still picture.

Compare to this aurora below (courtesy wikipedia).

Aurora Australis

However, I did find time to write the terrain chunk drawing loop, which implicitly builds a quadtree and tests at each recursive level the nodes of the tree against the camera frustum.

I discovered quickly that testing whether every single chunk is in the camera frustum or not is very expensive — 8 ms, which is half the time I have to do all draw thread computation at 60 fps.

In my previous terrain, where I used a quadtree for each chunk, the number of tests to see if a chunk was in the frustum was bounded, since the quadtree didn’t need to recurse all of the way, if the entire terrain was visible, since further blocks would simply be drawn larger.

In the new chunk LOD method, in the worst case, the entire terrain is visible and all blocks need to be drawn and tested, which takes 8 milliseconds to check, using 64×64 chunks and a 1024×1024 terrain heightmap.

On the XBOX (using only 1 core), using XNA’s BoundingSphere and BoundingFrustum classes, I can do about 40,000 sphere/frustum tests per second (600-700 per frame).

The GPU can test whether a triangle is in the frustum on the order of 100,000,000 times per second (over 1 million per frame).

The terrain chunks I’m using are 64×64 = 4096 triangles each. It is actually faster to send thousands of triangles to the GPU than to perform a single intersection test on the CPU. Unless of course, you’re GPU bound and have some CPU cycles to spare.

Exactly how my situation will turn out is to be determined, but I thought I’d emphasize just how large the processing speed difference is for this type of operation, between the CPU and the GPU on the XBOX with XNA.

In an effort to minimize the chunk drawing loop CPU time, I’ve also built a ReusableMinHeap class, which is a garbage-free min heap, which sorts the chunk draw calls for me from closest to furthest — to minimize overdraw. So far, it performs roughly the same as C#’s Array.Sort, which uses quick sort.

I’ll be happy to share the min heap class when the competition is over. Someone remind me.

By the way, here’s what the chunk-LOD terrain looks like so far:

The current state of the terrain as of March 19, 2011. Using 64x64 chunks and a 1024x1024 heightmap.

static string _backing; // Backing store for property
static string Property  // Getter and setter
{
    get
    {
        return _backing;
    }
    set
    {
        _backing = value;
    }
}
static string Field;    // Static field

public FieldPropertyTest(Game game)
    : base(game)
{

    long[] results1 = new long[10];
    long[] results2 = new long[10];

    Property = "string";
    Field = "string";
    const int m = 1000000;
    for (int x = 0; x < 10; x++) // Ten tests
    {
        Stopwatch s1 = new Stopwatch();
        s1.Start();
        for (int i = 0; i < m; i++) // Test property
        {
            Property = "string";
            //if (Property == "cat")
            //{
            //}
        }
        s1.Stop();
        Stopwatch s2 = new Stopwatch();
        s2.Start();
        for (int i = 0; i < m; i++) // Test field
        {
            Field = "string";
            //if (Field == "cat")
            //{
            //}
        }
        s2.Stop();
        results1[x] = s1.ElapsedMilliseconds;
        results2[x] = s2.ElapsedMilliseconds;
    }
}

The results:

Get:
Property: 341 ms
Field: 307 ms

Set:
Property: 85 ms
Field: 66 ms

This performance difference from the more robust .NET CLR used in Allen’s tests is owing to the fact that the .NET Compact CLR (which the Xbox 360 uses) doesn’t inline functions at all — to my knowledge.

Of course, the small size of the numbers above is good news — it took 10 million gets on a field to produce a 34ms difference.
It’s hard to imagine a scenario where using a field in place of a property would be a relatively large enough performance gain to affect your framerate.

There are also the usual caveats with micro-benchmarks like these, and the difference may be smaller (or larger) than what you see above, in real-world uses.

So, I’d take Jeff Atwood’s advice and simply always use (auto-)properties, unless you have a very tight performance sensitive loop that is accessing many properties.

Edit:
The NetCF team blog states that getters/setters are inlined, which is probably a source of some confusion. It’s also possible that my results above are wrong, if I’ve fallen into a micro benchmarking trap. Let me know if you find some results opposing what I’ve written above.

It turns out that this code was generating 7400 managed objects per second:

            text[0] = "FPS: " + fps.FPS.ToString();
            text[1] = "charPos: " + charPos.ToString();
            text[2] = "tLOD: " + tLOD.ToString();
            text[3] = "tTris: " + tTris.ToString();
            text[4] = "tBlocksDrawn: " + tBlocksDrawn.ToString();
            text[5] = "tBlocksCulled: " + tBlocksCulled.ToString();
            text[6] = "drawCodeTime: " + drawCodeTime.ToString();

A complicated optimization for code that isn’t even going to get compiled into the release build would be silly. The easiest fix here is to only periodically update the content of these strings (say, once per second, instead of once per frame.)
Also, some of the garbage generation could be reduced by separating the arrays into one array for the static strings “drawCodeTime: ” for example and then drawCodeTime.ToString() in a separate string. That would still leave thousands of objects per second created, sadly.

If you have a game that relies on many string conversions, your best bet is to use StringBuilder objects (which have predefined size) and replace subsections of those strings with the new string using the .Replace method that StringBuilders have built-in.