The Joy of Flex

Tuesday 8:30 am. Why do we care about memory management? We want our apps to run fast and run well. Users get mad if it’s slow. We want our apps to be stable, no leaks, no crashes, leave room for other apps to play. We want our code to hold up to scrutiny.

There are many times that excessive memory can be consumed. Large datasets, extended runtime requirements (hours/days/weeks), large forms with views and controls (e.g., home loan application), low-end hardware.

Demo: non-optimzed image browser app that loads a very large number of large images into memory before displaying anything: it hangs, you can see in task manager that it’s just sucking down memory and doing nothing else. Demo: optimized version of the same app, written differently: used much less memory, responded quickly to same user action.

(Side comment: he’s using an Eclipse plug-in called Snippets, looks like it’s a tool to manage code snippets, wonder what it is?)

The non-optimized verison was using a Tile container with a Repeater inside. A Repeater has to instantiate every instance in memory. The optimized verison was using a TileList, which only gets the visible instances, and gets more when it needs to (e.g., when scrolling).

Grant Skinner, Alex Harui are good bloggers to read on the topic of memory management.

Memory allocation in Flash Player: 1) Flex asks for small chunks frequently, player asks for larger chunk from OS more infrequently, can end up with larger memory footprint than your app is actually using.

Deallocation: garbage collection process will use deferred reference counting, and mark and sweep, to find unused memory and deallocate it.

Player garbage collection route deferred reference counting works by counting strong references, not weak references.

Mark and sweep starts at the root, works its way down the hierarchy of memory objects, memory used to store objects not reachable will be reclaimed.

Demonstration: Grant Skinner’s garbage collection simulator: www.gskinner.com/blog/archives/2006/09/garbage_collect.html.

Pros: performance, since it doesn’t run all the time and every time, it saves on processor cycles and response time. Cons: indeterminate, GC only runs when more memory is needed; iterative, may take a few passes to finish consolidating; and involuntary, there is no supported/recommended way for a developer to force GC.

Best practices — allocation concerns. With a dataset retrieved from a service, get an initial page of data, then get additional pages as needed. Paging is built into LCDS. Best practices — assets. Predict what your user is going to need and load only the minimal assets at first, then load more as needed.

Use deferred instantiation when possible. Be wary of creationPolicy=”all”. Try to avoid removeChild() / addChild() when it would work just as well to reuse an object or just toggle the visible property.

Modules: don’t unnecessarily load/unload modules. If you need to unload a module, make sure to remove all references pointing to it. In particular if you have an event listener from within the module to something outside the module, that can prevent the module’s memory from being reclaimed.

In AIR, you have to be careful with NativeWindow. After making a NativeWindow you must call close() before it can be GC’ed. But you must remove references before you can call close(). Also in AIR, when you open a FileStream object in asynchronous mode, pending event listeners can prevent the FileStream object from being GC’ed.

Demonstration of a memory analysis tool called Redbug that can graph the memory usage of a Flex application. Need to put calls to Redbug into hte app. See http://www.realeyesmedia.com/redbug/. Might be a useful tool for us, does things that the profiler doesn’t do.

Some interesting discussion about why the default value for the reference parameter in addEventListener() is false (strong reference) instead of true (weak reference), since a weak reference is often a better choice from the point of view of memory management. One good argument is that the default is strong reference because it makes the app more likely to behave correctly (vs. crash or fail) even at the expense of a memory leak.

What is available to help with memory management? Some tips on debugging and refactoring: during the testing phase, keep an eye on memory consumption and see what’s happening in the app when memory spikes. Try not to change too much code at once before re-testing. And keep old versions so you can compare between two different approaches.

Memory can be consumed by unexpected things: mouse movement, modal popups, service polling, scrolling within components. Don’t get too wrapped up in slight variances in memory allocation. Also keep in mind that a different interaction path will result in a different profile. So try to use non-interactive repeatable sequences.

In Flex 3 beta 1, there is a profiler that provides a lot of tools for looking at memory management, memory allocation, and so on.

To get an accurate number for how much memory the flash plug-in or the AIR runtime is taking, call System.totalMemory() — don’t rely on numbers from the Windows Task Manager. Note that System.totalMemory() reports the total combined memory of all therunning instances of the flash player, not just the currently running one.

Take a look at Grant Skinner’s Janitor class that manages all references to an object, you make all reference-related calls through the Janitor, then you can tell the Janitor to clean up all the references.

Technorati Tags: 360Flex