Flex/AIR Memory Profiling

15 05 2008

I’m entering the final stages of testing of my most recent Flex app and decided to start profiling this week. Everything I have since read on it suggests: Profile early, Profile often.

Oops.

Well, apart from spending almost two days pondering memory usage graphs (my major problem were significant memory leaks), I managed to get there and fix my major memory issues.

As it turns out, my major issues came from strong event listeners between static classes (my Remote Object services) and my modules. Garbage collecting modules is like components, you still have to ensure no other living parts of your application reference anything you’ve destroyed.

Stupidly, I spent a fair deal of time focusing on components that were added by my modules and were taking the most memory, instead of concentrating why the module itself was still residing in memory after i’d destroyed it. (The memory graph was nasty, lemme tell you).

One thing that I discovered after all that pondering, is that I would hope Adobe could clear up which references are strong and which aren’t. Looking through tens to hundreds of references

I am curious in the Silverlight vs Flex debate how well MS’s solution handles memory leaks and what options are available for profiling. I’m also interested to see how Adobe improves the Flash player now that they’ve created such a better model for developing Flash content: developers working in Flex/AIR, with the designers in Flash.

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: