I believe that the "elastic racetrack" was coined by Ted Patrick of Adobe evangelism fame... and it does a fine job as a visual aid in explaining Flex application performance.

So... here is a quick review of the elastic racetrack and how to get your Flex/AIR ponies running faster. By the way - this post is a summary of many great articles, materials, presentations I've collected. If you're hungry for more after reading... Google is your friend!

On Teb! On!

Flash’s refresh cycle is frame-based and can be divided into three groups of operations: script evaluation, invalidation, and rendering. The model or concept for a frame cycle has often been described as a circular racetrack... which is repeated once per frame.

The above image shows a frame that is divided equally between script evaluation/execution and rendering; which is ideal. In other words, there is a balance between script evaluation (handling events, user interaction, etc) and rendering (updating the UI to maintain parity with changes that occurred during script evaluation). Invalidation (the small green block between) is a natural consequence of script evaluation - in which ‘stuff’ may change.

There are times when changing ‘stuff’ requires long running processes, synchronous calls, large code blocks, loaders, and etc. As this happens, script evaluation may become predominant in the frame. If this happens... rendering may not be able to keep up with script evaluation which will cause the UI to feel un-responsive. Have you ever tried to load a large number of assets into your application at runtime and while that is happening mouse input becomes jerky?

Script evaluation can be tamed by operating in sequence rather than in parallel; load your assets one after the other. This may take slightly longer but the perceived performance of your application will be better. No one likes to use software that feels like it’s thrashing or is on the verge of crashing.

On the other hand... when rendering sits fat in the frame script evaluation tends to suffer. Performance is degraded as your ‘stuff’ changes are pushed to the next frame... and to the next... which triggers more display list updates ...which touches script evaluation ...and it becomes a vicious non-performant cycle.

Do you like to call invalidateDisplayList()? ...do you use object pooling? ...does deferred instantiation ring a bell? ...what does commitProperties() do? ...can you perform bulk updates on your data provider instead of continuous one-sies and two-sies? One of the best ways to see how good or bad your rendering cycles are is to turn on redraw regions (right click in the debug Flash Player window -> Show Redraw Regions). The smaller they are the better.