One of the most computationally expensive operations in the Flex component life cycle is the constructor and initialization routine. If you are adding and removing lots of complex components, this can become very taxing on the system, and reduce overall application performance. The more complex the component, the more taxing it will be. One way to reduce the impact that this has on your system is through object caching, (also known as object pooling).

Reduce, Reuse, Recycle
When using object caching, you create a cache of objects that the application can use. When the application is finished with these objects, you return the objects to the cache so that they can be reused again. This technique reduces the number of object instances created by the runtime, reduces the overall memory used when running the application, stabilizes the required resources to run the application (less spikes in both cpu and memory), and leads to better overall performance and scalability of the application when applied correctly.

Here is a sample project that demonstrates this technique and its benefits... There are two applications in the project. Both have identical functionality, however one implements object caching, and one does not. The sample applications demonstrate the memory and performance impacts by creating and removing 100 "CircleRenderer" objects on every "ENTER_FRAME" event.

In some senses, this example is very extreme because we are adding and removing 100 child objects in every "ENTER_FRAME" event. In other senses, this example is basic because the CircleRenderer itself is a very simple object. Objects that are more complex can require more resources to be created & rendered, even if they are not added and removed as frequently as this example. The CircleRenderer is a simple object that extends from UIComponent. It draws a circle, with a variable color and radius, and creates three TextFields inside of it. One contains a UID string, one displays the color, and one displays the radius value. All radii, color and UID values are randomly generated within the application.

First, let's look at the ObjectCache class, then we will get into the difference this technique makes:

public class ObjectCache
{
	private static var cache : ArrayCollection;
	private static const preCache : int = 100;
	
	public static function getRenderer() : CircleRenderer
	{
		var renderer : CircleRenderer;
		
		if ( cache == null )
		{
			cache = new ArrayCollection();
			
			for ( var x : Number = 0; x < preCache; x ++ )
			{
				renderer = new CircleRenderer();
				cache.addItem( renderer );
			}
		}
		
		if ( cache.length <= 0 )
			renderer = new CircleRenderer();
		else 
			renderer = cache.removeItemAt( 0 ) as CircleRenderer;
			
		return renderer;
	}
	
	public static function setRenderer( renderer : CircleRenderer ) : void
	{
		cache.addItem( renderer );
	}
}

You can see that there are two publicly exposed static methods on the ObjectCache class: getRenderer and setRenderer. The "getRenderer" method is used to retrieve a CircleRenderer instance from the cache. If the cache has not been initialized, it will precache 100 CircleRenderer instances in the cache. If the cache contains a renderer instance, it will remove a renderer from the cache and return it. If the cache is empty, it will simply return a new renderer. The "setRenderer" method just returns the renderer to the cache of available renderers.

Now, lets get into the application itself...

On every "ENTER_FRAME" event, the "No Cache" application removes all of the circle renderers from the container, and creates 100 new renderers:

private function onEnterFrame( event : Event ) : void
{
	circlesContainer.removeAllChildren();
	
	for ( var x : Number = 0; x < children; x ++ )
	{
		var renderer : CircleRenderer = new CircleRenderer();
		RendererUtil.updateRenderer( renderer );
		circlesContainer.addChild( renderer );
	}
}

On every "ENTER_FRAME" event, the "Cache" application removes all of the circle renderers from the container and returns them to the cache. It then adds 100 renderers to the container that are retrieved from the cache.

private function onEnterFrame( event : Event ) : void
{
	while ( circlesContainer.numChildren > 0 )
	{
		ObjectCache.setRenderer( circlesContainer.removeChildAt( 0 ) as CircleRenderer );
	}
	
	for ( var x : Number = 0; x < children; x ++ )
	{
		var renderer : CircleRenderer = ObjectCache.getRenderer();
		RendererUtil.updateRenderer( renderer );
		circlesContainer.addChild( renderer );
	}
}

The "RendererUtil.updateRenderer" method simply sets all the randomly generated values for the renderer component.

Now, the results...

In the application, there is also a performance monitor class, inspired by this one. This performance monitory tracks the current memory usage, the peak memory usage, and the history of the memory usage. Note: the performance monitor uses System.totalMemory to calculate the amount of memory used. This is the entire memory used by the flash player, so don't run both examples at the same time, or else your results will be skewed!

On my machine [Inte(R) Core(TM)2 Duo 2 GHz, 2 GB RAM], I ran these examples for 2 minutes apiece. The cached version had a peak memory usage of 10907648 bytes, and the non-cached version had a peak of 19681280 bytes. That's a difference of 8773632 bytes, or 8.36 MB. Not only does the cached version use less memory, it also has more consistent memory usage and cpu usage. (I wish I could track cpu usage in Flash/Flex, but unfortunately I haven't found a way yet.)

Both graphs shown here have the same horiztonal time scale (although the vertical scale is dependant upon the peak value). The two graphs show that the non-cached version had more frequent, and more drastic memory spikes, thus more frequent garbage collection.

You can run the applications yourself here (warning-CPU intensive code):
Cache:
http://www.cynergysystems.com/blogs/blogs/andrew.trice/objectcache/Cache.html
No Cache:
http://www.cynergysystems.com/blogs/blogs/andrew.trice/objectcache/NoCache.html

You can view the source at:
http://www.cynergysystems.com/blogs/blogs/andrew.trice/objectcache/srcview/

You can download the source at:
http://www.cynergysystems.com/blogs/blogs/andrew.trice/objectcache/srcview/ObjectCache.zip

Leave a comment!
Or, contact me directly here