   [.net] memory management (C#)
  Hi, in my 2D vertical scroller game, everytime the game advances to a new stage/level i notice the memory consumption goes up.(i.e. 1st stage 408mb, 2nd Stage 448mb, 3rd stage 480mb..) also, when i hit ESC to quit the game, the program shuts down a lot faster when it was on 1st stage, and the further stage into the game the longer time it takes for the program to shut down. at that rate, if my game had 10 stages in it, the computer eventually is gonna run out of memory and it's gonna take forever to shut it down. i think this is because i didn't properly release the resources whenever the game advances into the next stage.BTW, my program is written in C#, and the game uses a tile based background. each stage, the program loads from a .TXT file and translates it into a 2-D Array(tiles[,]).do i need to clear the tiles[,] at the beginning of each stage?  and how do i release all the resources when the program shuts down.could someone pls tell me how to properly manage the resources/memory. Thanks in advance.   
  Maybe try "forcing" the collector to deallocate all unused memory through the Sytem.GC.Collect() method.googling for "C# gc.collect" pulls up all kinds of hits on how to do manual collection. Good luck.   ;  [google] the clr profilerQuicky guidelines:Don't make deep copies of stuff unless you have tooDon't keep lots of references around to the same thing, it's harder for the GC to do it's jobTightly coupled classes (eg Class A has a member variable of type Class B, and class B has a member variable of type A) are pretty hard for the collector to deal withThe longer something is in scope, the more likely it is to be put in the pile of long term stuff the GC puts off doing for a whileRemember to use "using" around disposable typesRemember to close and dispose streams;  Also make sure you dispose Managed Direct X objects that aren't in the managed pool when you finish with them. And make sure you aren't still referencing objects from the previous levels anywhere. If you can still access instances of them anywhere in your code then they won't be collected by the garbage collector.   ;  how do i make sure that im not referencing objects from the previous level?;Quote:Original post by p997how do i make sure that im not referencing objects from the previous level?For anything you aren't using, make sure the references are null.Take care about things like loading an image for every single tile or whatever you are doing.  Load the image once, and reference that one instance elsewhere.  Stuff like that.   ;  In making sure that you don't hold any references to any objects not in use, make sure that you unsubscribe from any events you may have subscribed to on your objects, as many beginners don't realise that the events keep a reference to the object (search for "lapsed listener").To actually check what references are around in the system, to see whether you're referencing anything in the previous level, maybe downloading the CLR profiler would help?> Tightly coupled classes (eg Class A has a member variable of type Class B, and class B has a member variable of type A) are pretty hard for the collector to deal withIs this true? Surely the GC just checks whether there are references to these objects from the root references.   ;Quote:Original post by taumuonIn making sure that you don't hold any references to any objects not in use, make sure that you unsubscribe from any events you may have subscribed to on your objects, as many beginners don't realise that the events keep a reference to the object (search for "lapsed listener").To actually check what references are around in the system, to see whether you're referencing anything in the previous level, maybe downloading the CLR profiler would help?> Tightly coupled classes (eg Class A has a member variable of type Class B, and class B has a member variable of type A) are pretty hard for the collector to deal withIs this true? Surely the GC just checks whether there are references to these objects from the root references.Depending on how complicated the graph is (the relationships between the objects and those they reference), the CLR *may* take multiple passes to determine that the object is suitable for collection.  I say *may* because there are so many different factors (like size and type of object) that may effect this.Unfortunetly I have no code I can share to prove what I say in a profile (cos it's not mine, it's my employers I guess), but I'm sure in .Net 1.1 at least that improving class structure to not need duplex links maintained like that did improve the memory foot print of the application. The event handling thing was a good call actually, I forgot to put that down.WritefriendlierCodeGC is a pretty good article with links.   ;  The .Net GC only takes one pass to collect anything that is not in use (for the particular generation of course, GC0 will never touch generation 1 objects). Its a mark and sweep algorithm. Complexity of references between objects makes no difference the dependency tree is walked from the root objects and everything that is referenced is marked. Then the memory is compacted removing those items not marked. See Mark and sweep. There's a Jeff Richter talk out there somewhere where he walks through the GC process.The only things that cause separate passes are objects that have finializers implemented. In that case the objects are marked as such and a finalizer thread will eventually all the finalizer. This means anything with a finalizer will always move to the second generation - so avoid these unless absolutely required;Quote:Original post by thezbufferThe only things that cause separate passes are objects that have finializers implemented. In that case the objects are marked as such and a finalizer thread will eventually all the finalizer. This means anything with a finalizer will always move to the second generation - so avoid these unless absolutely requiredOr use GC.SuppressFinalize(object).