Does browsing the samples at www.degrafa.org make you weak in the knees? Planning to name your next child or pet commitProperties? Experimentation leads to discovery, discovery leads to inspiration, and inspiration leads to more experimentation... a delicious cycle that can result in a dangerous addiction to which profiling is the only cure.

We've all done it... one day you're out surfing the internets and BLAM! Some kin of Thor, skilled in the art of flexFOO(), has taken a UI concept and wrapped it in Flex; defying the limits of awesomeness. As we regain composure from the thrill of our savory and sweet discovery we, as all geeky-mortals, are overwhelmed with the desire to use that source in a product that is scheduled to ship next week.

"But it's just a sample!", your conscience screams. Bah! "Including it in your application may cause memory leaks!" Double bah! Ok... so, there is only one way to stop your conscience from nagging you and to keep your component appetite in check - due diligence with the profiler. There, I said it - PROFILE IT!

The reality? Bugs are bugs... but in the Flex world just because a sample or component compiles doesn't mean that it's ready for prime-time. It's because of this that I would like to share my personal four step program that leverages application profiling to help you manage the effects of Obsessive Compulsive Component Addiction Disorder (OCCAD).

Profile in an application context
If you are going to use the sample / component in a module within your application then create a project (test harness) that parallels your final modularized implementation - run / profile the project. Make sure to include a means to add and remove the target programmatically. I won't get into this now, but doing this will help set the stage for finding leaks, taking memory snapshots, and finding loitering objects. Just keep in mind that memory consumption is highly dependent upon the complexity of your source bits, controls, components, etc. and any data consumed. What you see in the memory usage window should be a reasonable representation of what it (the source) is and does. No surprises? Passed the smoke-test?

Profile with data
Slapping some data driven source or a component on a canvas and plumbing its data provider with a few records isn't going to cut it. You should be using a wide range of data (quality and quantity) when testing components. Data sources that give you 10, 100, 1000, and 10,000 records at a time is a good start and will help identify operational sweet spots.

Data loaded? Good... reload it again. Did the memory footprint continue to grow? Remove the source / component from the application programmatically and run the garbage collector - did current memory drop? Re-add the subject and try loading data from a secondary source. Does it look like it's behaving?

Rinse. Wash. Repeat. If everything looks good at this point... nice. Take a break and read this little gem by Grant Skinner. It's an older article but still a valid / good read on Flash memory management.

Beware the tweak!
This might be obvious but lets put it on the table just to make sure we are all on the same page; 'tweaking' source typically invalidates profiling data. When you are checking source in be on the lookout for changes around data providers, events, loaders, skinning, and whatnot. If you find any, find out who committed the code, and ask them if they have profiled the changes. Not everything will need to be re-profiled every time you find a change... but save your test projects just in case!

...and now a word from our sponsors about external repositories.

Open source projects are sweet... but I wouldn't mingle code in an external repository (e.g. Google Code) with my local / production workspace; insulate || die.

Profile often
The only way you are going to keep your application running optimally is to make sure it gets regular tune-ups. A quick check in profiler before each commit is a good idea (a safe monitoring mechanism for all those sweet / new code bits you've found). As with all maintenance... consistency is the key. Be wise, what can I say more?

Not convinced yet? Here is a screen capture of the memory footprint of a cool image control... that doesn't manage caching very well and to which the garbage collector was powerless against. Names have been blurred to protect the innocent!

This is an extreme case... hopefully it's vivid enough to keep you on the path to recovery!