Wikipedia defines a memory leak as “a particular type of unintentional memory consumption by a computer program where the program fails to release memory when no longer needed. This condition is normally the result of a bug in a program that prevents it from freeing up memory that it no longer needs” (http://en.wikipedia.org/wiki/Memory_leak).

Flash Player offers help in dealing with memory leaks. A special process called Garbage Collector (GC) periodically runs and removes objects from memory that the Flex application no longer uses. It counts all references to each object in memory, and when it gets down to zero, the object is removed from memory.

In some cases, two objects have references to each other, but neither of them is referred to anywhere else. In this case, the reference count never becomes zero, but Flash Player tries to identify such situations by running a slower method called mark and sweep.

Sure enough, you need to write code that nullifies reference variables that point to objects that are not needed (myGreatObj=null;): if you call addChild(), be sure not to forget about removeChild(); if you call addEventListener(), keep in mind removeEventListener().

The function addEventListener() has three more optional arguments, and if the last one is set to true, it’ll use so-called weak references with this listener, meaning that if this object has only weak references pointing to it, GC can remove it from memory.

Of course, if you ignore these recommendations, that’ll lead to littering RAM with unneeded objects, but your main target in optimization of memory consumption should be the unloading of unneeded data.

myButton.addEventListener("click",
         function (evt:MouseEvent){//do something});

var conn1:LocalConnection = new localConnection();
var conn2:LocalConnection = new localConnection();
conn1.connect("MyConnection");
conn2.connect("MyConnection");

Flex compiler is actually a set of subcompilers converting your ActionScript and MXML code into different formats. For example, besides mxmlc and compc, there is a precompiler that extracts the information from the precompiled ActionScript Byte Code (ABC). You can read more about compilers at http://opensource.adobe.com/wiki/display/flexsdk/Flex+3+Compiler+Design. The ABC is the format that Flash Player runs. But the story doesn’t end here.

Most of the performance advances in the current version of AS3 as compared to AS2 are based on its just-in-time (JIT) compiler, which is built into Flash Player. During the .swf load process, a special byte code verifier performs a lot of code analysis to ensure that code is valid for execution: validation of code branches, type verification/linkage, early binding, constants validation.

The results of the analysis are used to produce machine-independent representation (MIR) of the code that can be used by the JIT compiler to efficiently produce machine-dependent code optimized for performance. Unlike Flash VM code, which is a classic stack machine, MIR is more like a parsed execution path prepared for easy register optimization. The MIR compiler does not process the entire class, though; it rather takes an opportunistic approach and optimizes one function at a time, which is a much simpler and faster task. For example, the following is how the source code of an ActionScript function is transformed into the assembly code of the x86 Intel processor.

In ActionScript 3:

function (x:int):int {
return x+10
}

In ABC:

getlocal 1
pushint 10
add
returnvalue

In MIR:

@1 arg +8// argv
@2 load [@1+4]
@3 imm 10
@4 add (@2,@3)
@5 ret @4 // @4:eax

In x86:

mov eax,(eap+8)
mov eax,(eax+4)
add eax,10
ret

The difference in time for execution of the ABC code and x86 can be on the order of 10 to 100 times and easily justifies having an extra step such as the JIT process. In addition, the JIT process does dead code elimination, common expressions optimization, and constants folding. On the machine-code generation side, it adds optimized use of registers for local variables and instruction selection.

You need to help realize these benefits by carefully coding critical (as opposed to overoptimized) loops. For example, consider the following loop:

for (var i:int =0; I < array.length; i++) {
    if( array[i] == SomeClass.SOMECONSTANT)...

It can be optimized to produce very efficient machine code by removing calculations and references to other classes, thus keeping all references local and optimized:

var someConstant:String = SomeClass.SOMECONSTANT;
var len:int = array.length;

for (var i :int = 0; I < len; i++) {
    if (array[i] == someConstant)

JIT is great at providing machine code performance for heavy calculations, but it has to work with data types that the CPU is handling natively. At the very least, in order to make JIT effective, you should typecast to strong data types whenever possible. The cost of typecasting and fixed property access is lower than the cost of lookup, even for a single property.

JIT works only on class methods. As a result, all other class constructs—variable initialization on the class level and constructors—are processed in interpreter mode. You have to make a conscious effort to defer initialization from constructors to a later time so that JIT has a chance to perform.

The Flash Builder Profiler monitors memory consumption and the execution time. However, it monitors very specific execution aspects based on information available inside the Virtual Machine and currently is incomplete. For example, memory reported by the Profiler and memory reported by the OS will differ greatly, because the Profiler fails to account for the following:

More importantly, when showing memory used by object instances the Profiler will report the size used by object itself and not by subobjects. For example, if you are looking at 1,000 employee records, the Profiler will report the records to be of the same size, regardless of the sizes of last and first names. Only the size of the property pointing to the string values is going to be reported within the object. Actual memory used by strings will be reported separately, and it’s impossible to quantify it as belonging to employee records.

The second problem is that with deferred garbage collection there are a lot of issues with comparing memory snapshots of any sizable application. Finding holding references as opposed to circular ones is a tedious task and hopefully will be simplified in the next version of the tool.

As a result, it is usually impractical to check for memory leaks on the large application level. Most applications incorporate memory usage statistics like System.totalMemory into their logging facility to give developers an idea of possible memory issues during the development process. A much more interesting approach is to use the Profiler as a monitoring tool while developing individual modules. You also need to invoke System.gc() prior to taking memory snapshots so that irrelevant objects won’t sneak into your performance analysis.

As far as using the Profiler for performance analysis, it offers a lot more information. It will reveal the execution times of every function and cumulative times. Most importantly, it will provide insights into the true cost of excessive binding, initialization and rendering costs, and computational times. You would not be able to see the time spent in handling communications, loading code, and doing JIT and data parsing, but at least you can measure direct costs not related to the design issues but to the coding techniques.

While planning for performance improvement of your RIA, consider the following five categories.