:cubicleman.com

I am currently working with a client doing performance profiling and adjustments for a medium sized application. After using the profiler in Flex Builder, a painful experience for me not having worked with such a animal, I found a area that was exhibiting a major memory leak. Well, maybe memory leak is not the correct term, a certain area of the application had a view stack that would add children to it. The user could then remove the children. This removal never released memory. In other words a removeChild() removed the child element, but since the child had some external references to it, this child was never garbage collected.

Now, a few hours digging in the memory profiler didn’t help me find where the nastiness was happening, more on that later maybe. Anyone out there care to shed some tips on this?

Recalling Jun Hieder’s presentation at 360|Flex Atlanta, I started digging into event listener additions, these guys can add a case of the nasties to the situation. That’s when I stumbled upon the use of BindingUtils.bindProperty. The basic approach was that a class A had a property bound to a property in class B using BindingUtils.bindProperty in a util class. This added a hard reference to A in this case, which would keep A from getting GC’d if need be.

This begs the question, why use this? The need here was to inject data into B from A. Probably better to say use A.property = B.property in A or a third party class. If you need it to change at runtime dynamically, have A dispatch a event that can be heard and reacted to, passing the data in the event along the way.

I have attached a sample application that displays the characteristics described above. Use the profiler in Flex Builder to see what happens after manually running a GC. You can grab it here BindingUtils Test

off to refactor!

peas

DK