code++

Recently as I continued my miserable everyday struggle with Flex and it’s incredibly slow IDE Flex Builder, I have made yet another discovery that of course is not documented about Flex. I am involved in building high end flash sites everyday and thus far on all of them I have created them as modular style Flex applications using Flash to provide some very crafty assets. On one of the most recent sites I was working on I eventually ran into a huge problem.

The Problem:

The site had a major memory link throughout the modules. I had ultimately determined that this leak was caused by Flex’s mx.controls.VideoDisplay class since I use it in the majority of the modules of the site. The overall problem is that I couldn’t force the unloading of the modules while using the ModuleLoader class. Now this wouldn’t be that big of a deal because I could just not unload each module and instead let the ModuleLoader class retain each module’s instance in memory for later use when loaded again. Well here is where the next big problem came into play, for reasons I still haven’t pen pointed while sorting through the module system’s source code, the ModuleLoader class creates a new instance out of the loaded module every time you call it to be loaded and it does this with the assumption that the old module would always successfully unload first. This assumption has rendered the ModuleLoader class useless when you are experiencing a memory leak within a module that you cannot get rid of. What the result of this problem was is a high end flash site that perpetually grows in memory every time you visit a section of the website, regardless if you have already loaded it once. After browsing this site and hitting random sections for about 10 minutes this would bump Internet Explorer’s running RAM usage up to about 350 to 400 mbs which was clearly unacceptable for it would have kept climbing if I didn’t stop. Also to mention the many other problems this caused with reference less modules floating around in memory still doing their “own damn thing” as they please because they were attached to some globally controlled events.

The Solution:

As this major problem needed a solution and a solution quick I took full and manual control of the loading and handling of the modules by dropping the ModuleLoader class and using the ModuleManager class instead. This nifty class allows to you directly work with the IModuleInfo interface’s that handle the loading and creation of each module used. What I did with this was store a reference to the IModuleInfo instance for each module I loaded in an object using the module’s url as a key/value pair map. This way I could check the status of each module I was trying to load and create one and one instance only of each when it was loaded which I then stored the actual display objects generated from the IModuleInfo in a map of their own allowing me to call them up at anytime I needed to. My ending result was a website that took no more than 150 mbs in RAM once all the modules have been loaded once. Not to mention the performance increase as well when you aren’t recreating a new instance of a module every time you want to use it.