I don't really use special tools to catch leaks like this... I just stumbled upon it when I saw the memory footprint go up, although I was not doing anything like moving the camera. I thought it would settle after a while, but the memory use kept going up.
Since I'm terrified by memory leaks from years of C++ coding, I started looking on the internet for ways where .net might also have leaks, although there is the magic Garbage Collector. It's very handy, but it also takes away our awareness of leaks and garbage, which might bite you in the back in games...
As it turns out, there are some things recommended in several texts that you should do or not do in games:
- don't use use foreach in tight rendering loops, because alledgedly is spwans an iterator each time, which needs to be garbage collected
- don't use use of lot of on-the-fly 'new', where you could also allocate objects at the start of object existence, and then just fill in their values later (like a Vector3, etc. ?), keeping the same object alive, instead of allocating a fresh one every time
- do recycle objects instead of re-allocating them each time, if possible. I always use an 'active' and a 'recycled' collection for this purpose, in my classes, between which I actively recycle objects so that they stay out of reach from the Garbage Collector. An old PocketPC development habit, I guess.
- do use the 'using' statement at specific points, for making sure an object is deleted straight after using it
- watch out for hidden 'boxing' of objects (which what I think is going on in the tutor 6 leak, right?)
the rest is a matter of memory-leak-allergy and trying to weed out the possible culprits like a honeybadger that doesn't want to let go of his victim. (honeybadgers are known to do that, I read while hunting for memory-leak-tips on the net
As a debugging strategy, I use an approach (very simple, really) that always worked for me, and is based on narrowing down the lines of code where stuff might happen: (like probably every coder has his or her own habits in this way)
- make a LOT of the objects you want to test for leaking, so leaks show up bigger and faster
- if you see a leak, keep an eye on the memory use in Task Manager or similar memory-tools... if it goes up even if you don't do a thing, and doesn't settle after a while, it's definitely leaky.
- next, I usually outcomment pieces of code, until I see different behaviour... starting with a big piece, then less and less, until I get around to the line of code that seems to do it.
so far for my 'tools' of pigeon logic ;-)
any chance that the tutor might be fixed for this little adaptation, as it's a bit a nasty one?
I don't know if the solution with the 'using' statement is the only/best one, but it worked here.
I also tried calling the garbage collector on a regular basis.. every 5 seconds or so, on all GC generations (which is definitely a bad way of doing it, if I read the XNA blogs, because it throws away performance, also when it collects nothing) but that doesn't even make a difference for this leak... rather peculiar, no?
kind regards!
loki
