How are you programming in C# and you don't know what garbage collection is? It's one of the most basic topics in C# and affects everything you do with it.

Garbage collection means that you don't have to handle de-allocating your objects, because the collector stops the program every now and then, and cleans up all the old resources that are no longer being used. This is not free, and there is a time cost to do this as the GC checks over the entirety of your allocated memory for dead resources to free. In more complex programs with lots of memory overhead, or frequent resource allocations this can introduce stuttering, and possibly lag in extreme cases.

A good way to avoid this is to make a fixed pool and allocate it up front. Then you can mark entries in this array/list/whatever as dead and re-use a dead entry when you need a new one. http://blog.gallusgames.com/programming/lean-mean-object-pool-in-c

Also, are you sure that you are properly killing off populations, and that the program isn't just doing more and more work as the game progresses?

Hey so in the past I've been very interested in making simulations of evolving interesting behaviors between artificial intelligent agents. Obviously this sort of simulation is a whole lot of creating populations, killing them, creating more, killing them over and over. I've always had this problem, though, where as the program would run it would slowly get more and more laggy, until maybe thirty minutes into the simulation the lag would be so bad I'd have to stop it altogether. I've heard of this thing called "garbage collection" and suspect that is the issue, but I've got no idea what it entails. Does anyone have any advice to offer?

Sounds like your code is the problem; not the language or runtime. Since you're talking about garbage collection as if it were some mysterious thing you've only heard of before I assume you don't have a lot of C# experience or intimate knowledge of the language and CLR. But the type of project you're working on seems to suggest you have some significant programming experience in general (come from a C++ background?). So I suggest that you get a good book on modern C# and CLR and learn all the ins and outs of the language and how the runtime works; then leverage that knowledge to fix your code.

I've run flight simulations in C# that performed every bit as fast as comparable simulations written in C or C++, and could sometimes be about 36% faster. So there's little doubt in my mind that C# itself is NOT causing the problem. In general, C# applications have smaller memory footprints than native applications and are much more memory-efficient; and automatically managed memory can virtually eliminate memory leaks (save when dealing with native resources and unmanaged memory). This, alone, can make C# applications outrun comparable native applications, and C# has other significant advantages as well. So don't blame the language or the CLR; blame the application!