This is a story that happened today…after using Flixel, an AS3 game framework, for a good number of months.
So, garbage collection in flash/as3 or whatever. AFAIK, garbage collection is an algorithm object-oriented programming languages implement in order to free up memory that had been allocated earlier. In some ways, a more friendly alternative to the malloc/free of C we (maybe) all know an dlove.
Flixel works in these objects called “FlxStates” which, in some ways, act as things you can stick objects you want to display in. Say I switch from a menu to the world map, which are both modeled as FlxStates. I had naively assumed that in doing so, Flixel would have marked all of the objects I added to it as null in its call to the FlxState’s destroy(), so that they would be freed from memory by the garbage collector. To my surprise, today I pop open the code for FlxGroup (the class FlxState extends)’s “destroy” method and…
public function destroy():void {}
oh, shit.
For some reason since memory management isn’t so explicit (see: C programming language) in as3, I somehow assumed that flixel would deal with the marking of things as null, but this is behavior that has to be customized.
Using a framework, really the only things that I allocate that AREN’T added to the FlxState are arrays of strings or whatever. So it was just a straightforward exercise of null’ing the objects in the FlxState one by one when switching states.
And that fixed everything…more or less. Before, at least 20-30 MB were being allocated whenever I entered a stage, some of that being freed (or reused? not sure) when I re-enter stages. Of course, that adds up over time, although on full one-sitting test plays I never noticed a problem. Probably because we’re so spoiled with memory nowadays… 🙂
Anyways, a game I had worked on for a few months now runs a few FPS faster than I ever thought it could. Luckily, this didn’t cause too much problems with the game design I made while playing it slow.
So, rookie error. But better late than never, right?