Keeping an application properly 'tuned' can be tricky business... performance isn't a switch you flip just before you ship.

I'll start with the moral of the story:

Developers should always be on the lookout for potential issues that can destabilize an application... every change has the potential to improve or erode performance.

Changes? Yes... like moving to a new Flex SDK version.

I would have fallen asleep last night at a reasonable hour if it weren't for the rude interloper that went tromping through my semi-consciousness; an interesting idea for a future blog post. Does this kind of thing happen to anyone else?

For me, the best way to deal with unscheduled moments of inspiration is to get up and sit down at my desk and plunk out a skeleton of what's rolling around in my tubes before heading back to bed. To help decipher my grog-sessions (e.g. late night groggy coding sessions) I usually do a screen recording and talk through what I'm doing. I used to keep a pad of paper by the bed for these moments - but deciphering the unintelligible chicken scratch the next day… not good. Moving along!

I was only a few minutes into coding my sample when I noticed a whole bunch of item renderers that weren't getting GC'd (garbage collected). Yes, I'm OCD about running the profiler periodically as I code… even with samples.

No heading back now right? I might as well dive in and track down the leak. Within ten minutes I had identified two potential offending classes, yanked them out of the Flex Framework, and plopped them in my project. I was surprised - TileBase.as and ListBase.as were pretty well behaved in the Flex 3.3 SDK. Oh… that's right - I upgraded to Flash Builder 4 and was now working with Flex 3.5 as my default SDK. Nevermind.

Before I go any farther, I want to say that this isn't an Adobe bash. For perspective, consider the following 'blips' about software development.

• software is never 'done' is just ships
• aim for quality - but realize that software without bugs is a fantasy
• for developers, a deep knowledge of the tools, frameworks, and components you use can greatly improve the quality of the software you write (e.g. gracefully side-stepping obstacles)
• scope-limited samples that expose the root cause of a bug / defect are invaluable in iteration (making things better - for everyone)

[ back to the grog-session ]

At lunch the next day I watched the screen recording and was surprised at how awake I sounded. Heh. Anyway, my original blog idea (Ruminations on Dynamic Lists) transmogrified into a full-blow episode of Flex Framework Defect Mitigation. Hmm… from a performance and architectural perspective... something more valuable than my original stream which I've decided to share.

I've cut the fat around the video clip to the meaty part where I've already identified the two classes that are giving me fits: TileBase.as and ListBase.as. I apologize for the video quality - it's small and difficult to see exactly what's going on. The list below the clip should help improve your take-aways.

[ time ]   [ description / what's happening ]
00:08 --- memory snapshots are incredibly valuable in examining connective tissue between objects - e.g. leak fodder
00:28 --- drilling into a memory snapshot to see who's touching what (profiler is worth its weight in unobtainium)
01:20 --- you can use callLater to 'schedule' work in the future... used sparingly it can be invaluable
01:45 --- GC isn't magic - make it a habit of cleaning up what you throw down
03:02 --- monkey patching framework bits isn't pretty - I'm doing it here to get to the bottom of the leak... would I include my patched class in a mission critical application? Depends.
03:48 --- crazy mouse position bug where the mouse location isn't being reported correctly (nice).
04:25 --- using command / control click through on objects or methods is awesome
05:15 --- rage starting to set in…
05:34 --- discovering all kinds of new 'management' fragments that are added to TileBase.as / ListBase.as
06:00 --- mx_internal - making it public… (don't hate me)
06:45 --- DUDE!
07:15 --- more mx_internal badness…
07:59 --- GC will run just before performing a memory snapshot - WHICH SAVED MY COMPUTERS LIFE!

The moral of the story... wait - I already shared that.