Ok well I dont think the world is in danger of utter damnation due to a tiny memory leak
I just checked and he is right - it's using up a good 18 KB or so every second, as a matter of fact. That isn't a memory leak per se, since it looks like it's being automatically recovered by the GC, but it is a good idea to ensure that your apps aren't allocating memory in the game loop.
edit..
i managed to extract your game and get the source
and it could be you setting the strings in the update method
but its more likely from your draw code, its hard to know without being able to hand test it (i dont want to take the time to fully hack it)
I don't see why it matters like at all. Why go through the process if no one who actually uses it notices it.
Moreover, it's not a memory leak - it's performing allocations in the game loop that eventually get GC'd later. If you take a look at the peak allocations line in the performance monitor, you'll notice it never goes far beyond 2 MB, which is perfectly reasonable.
still technically a memory leak, but the garbage collector sees it and cleans it up..
If that's a memory leak, then every .NET app leaks memory like a sieve. That's how .NET works. Of course, on an embedded platform like the Zune, it's a good idea to minimize heap allocations, especially in the game loop, but quite often such allocations are a necessary evil.
You do realize the line in the RPM you're looking at represents total all-time allocations, not the amount of memory currently allocated, right?
.
