Memory Profiling in Flex/AS3 and Performance Centrique Coding

I started off my programming life in C++.  To this day, I love the agility you have to manipulate hardware, memory, and the performance you gain from having direct access to the previous two.  I started using Java, and I felt although it made certain things simpler, the performance hit that using a VM caused was to significant.  Especially since I am a perfectionist.  This left a bad taste in my mouth for many years about anything that used a VM or any kind of intermediary, like .Net.  Well, I finally overcame all of that and fell in love with C#, it is my language of choice these days when writing Windows only code.  But, to get on to the real topic I wanted to discuss.

When I started working with Flex and AS3, I noticed that it was exceedingly easy to throw together an application, even easier if you have had some experience building some of these applications in the past with Flash.  But, I also noticed it was all to easy to be very sloppy, and this also left a bad taste in my mouth because I noticed how easy it was to create memory leaks, and bog down an application with multiple requests, etc..  Well, Adobe has come out with a Profiler as a part of Flex Builder 3 that, even though I haven’t used it a ton, is the first step in building Rich Internet Applications which are hardware/memory/performance centrique.

A blog post I came across the other day on  InsideRIA was all about this profiler, but also on some other issues of memory leaks.  The main thing that I was unaware of was how easy it is to generate massive memory leaks through unremoved eventlisteners.  The post is here . Some of the highlights that I was interested in though where:

1. When adding an eventlistener to an object, we are creating a reference to that object, so even after that object falls out of scope or has been removed from the display list, the GC will not pick it up because it will still show that there is a reference pointing to that object.

2. Using weak references for event listeners, (the 5th parameter when using addEventListener), somewhat overcomes this.  If you set this flag to true, when the GC checks an object for references, and the only references to that object are “weak” references, it will mark it for collection.  This potentially frees up massive amounts of memory.

3. Use removeEventListener whenever possible, to keep your code concise and performing well.

I will post some more about the profiler after I run some tests this week using it on some applications that my company has built previously.  This will prove to be most interesting, and most likely somewhat depressing.

Until then…

~ by ninjadeveloper on June 17, 2008.