Specifications

CHAPTER 4

• Do not attempt to test a large application’s performance all at once. Rather, test small pieces of the application

so that you can focus on the relevant results instead of being overwhelmed by data.

• Test the performance of your application early and often. It is always best to identify problem areas early and

resolve them in an iterative manner, rather then trying to shove performance enhancements into existing, poorly

performing code at the end of your application development cycle.

• Avoid optimizing code too early. Even though early testing can highlight performance hot spots, refrain from

fixing them while you are still developing those areas of the application; doing so might unexpectedly delay the

implementation schedule. Instead, document the issues and prioritize all the performance issues as soon as your

team finishes the feature implementation.

Testing applications for performance

You can use various techniques to test start-up and run-time performance of your Flex applications, such as

monitoring memory consumption, timing application initialization, and timing events. The Flex profiler provides

this type of information without requiring you to write any additional code. If you are using Flex Builder, you

should use the profiler for testing your application’s performance. For more information, see “Profiling Flex appli-

cations” on page 155 in Using Adobe Flex Builder 3.

Calculating application initialization time

One approach to performance profiling is to use code to gauge the start-up time of your application. This can help

identify bottlenecks in the initialization process, and reveal deficiencies in your application design, such as too

many components or too much reliance on nested containers.

The

getTimer() method in flash.utils returns the number of milliseconds that have elapsed since Adobe® Flash®

Player or Adobe AIR™ was initialized. This indicates the amount of time since the application began playing. The

Timer class provides a set of methods and properties that you can use to determine how long it takes to execute

an operation.

Before each update of the screen, Flash Player calls the set of functions that are scheduled for the update.

Sometimes, a function should be called in the next update to allow the rest of the code scheduled for the current

update to execute. You can instruct Flash Player or AIR to call a function in the next update by using the

callLater() method. This method accepts a function pointer as an argument. The method then puts the

function pointer on a queue, so that the function is called the next time the player dispatches either a

render event

or an

enterFrame event.

The following example records the time it takes the Application object to create, measure, lay out, and draw all of

its children. This example does not include the time to download the SWF file to the client, or to perform any of

the server-side processing, such as checking the Flash Player version, checking the SWF file cache, and so on.