About profiling and how the profiler works

The profiler helps you identify performance bottlenecks and memory leaks in your applications. You launch it from within Adobe Flash Builder, and as you interact with your application, the profiler records data about the state of the application. The recorded data includes the number of objects, the size of those objects, the number of method calls, and the time spent in those method calls.

Profiling an application can help you understand the following about your application:

Call frequency
In some cases, computationally expensive methods are called more than once when multiple calls are not necessary. By identifying the most commonly called methods, you can focus your performance-tuning time on a smaller area of the application, where it can have the most impact on performance.

Method duration
The profiler can tell you how much time was spent in a particular method. Or, if the method is called multiple times, what the average amount of time spent in that method was during a profiling section. If you discover that some methods cause a performance bottleneck, you can try to optimize those methods.

Call stacks
By tracing the call stack of a method, you can see the entire path that the application takes as it calls successive methods. You then sometimes discover that methods are being called unnecessarily.

Number of instances (object allocation)
You sometimes discover that the same object is being created many times, when only a specific number of instances are required. In these cases, you can consider implementing a Singleton pattern if you really require only one of those objects. Or you can apply other techniques that reduce excessive object allocation. If the number of objects is large, but necessary, you can consider optimizing the object itself to reduce its aggregate resource and memory usage.

Object size
If you notice that some objects are disproportionately large, you can try to optimize those objects to reduce their memory footprint. It is especially helpful if you optimize objects that are created many times in the application.

Garbage collection
When comparing profiling snapshots, you sometimes discover that some objects that the application no longer requires are still "loitering", or are still stored in memory. To avoid these memory leaks, you add logic that removes any remaining references to those objects.

Profiling is an iterative process and a part of each step of application development. To quickly identify problem areas and gain the most benefit by profiling, it is recommended that you profile the application early and as often as possible in the development cycle.

    How the profiler works

    The profiler is an agent that communicates with the application that is running in Flash Player. It connects to your application with a local socket connection. As a result, you might have to disable anti-virus software to use it if your antivirus software prevents socket communication.

    When the profiler is running, it takes a snapshot of data at short intervals, and records what Adobe Flash Player is doing at the time. This is called sampling. For example, if your application is executing a method at the time of the snapshot, the profiler records the method. If, by the next snapshot, the application is still executing that same method, the profiler continues to record the time. When the profiler takes the next snapshot, and the application has moved on to the next operation, the profiler can report the amount of time it took for the method to execute.

    Sampling lets you profile without noticeably slowing down the application. The interval is called the sampling rate, and it occurs every 1 ms or so during the profiling period. This means that not every operation is recorded and that not every snapshot is accurate to fractions of a millisecond. But it does give you a much clearer idea of what operations take longer than others.

    By parsing the data from sampling, the profiler can show every operation in your application, and the profiler records the execution time of those operations. The profiler also records memory usage and stack traces and displays the data in a series of views, or panels. Method calls are organized by execution time and number of calls, as well as number of objects created in the method.

    The profiler also computes cumulative values of data for you. For example, if you are viewing method statistics, the cumulative data includes the time and memory allocated during that method, plus the time and memory allocated during all methods that were called from that method. You can drill down into subsequent method calls until you find the source of performance problems.

    Types of profiling

    Before you use the profiler, decide on what profiling you are going to do: performance profiling or memory profiling.

    Performance profiling is the process of looking for methods in your application that run slowly and can be improved. Once identified, these hotspots can be optimized to speed up execution times so that your application runs faster and responds more quickly to user interaction. You generally look for two things when doing performance profiling: a method that is called only once but takes more time to run than similar methods, or a method that may not take much time to run but is called many times. You use the performance profiling data to identify the methods that you then optimize. You might find that reducing the number of calls to a method is more effective than refactoring the code within the method.

    Memory profiling is the process of examining how much memory each object or type of object is using in the application. You use the memory profiling data in several ways: to see if there are objects that are larger than necessary, to see if there are too many objects of a single type, and to identify objects that are not garbage collected (memory leaks). By using the memory profiling data, you can try to reduce the size of objects, reduce the number of objects that are created, or allow objects to be garbage collected by removing references to them.

    Memory profiling can slow performance of your application because it uses much more memory than performance profiling. Do memory profiling only when necessary.

    You often do both performance profiling and memory profiling to locate the source of performance problems. You use performance profiling to identify the methods that result in excessive memory allocation and long execution times. Then, you use memory profiling to identify the memory leaks in those methods.

    When you know what profiling you are going to do, you can start the profiler.

    Profiling APIs

    The profiler uses the ActionScript APIs defined in the flash.sampler.* package. This package includes the Sample, StackFrame, NewObjectSample, and DeleteObjectSample classes. You can use the methods and classes in this package to write your own profiler application or to include a subset of profiling functionality in your applications.

    In addition to the classes in the flash.sampler.* package, the profiler also uses methods of the System class.

    Internal player actions

    Typically, the profiler records data about methods of a particular class that Flash Player was executing during the sampling snapshot. However, sometimes the profiler also records internal player actions. These actions are denoted with brackets and include [keyboardEvent], [mark], and [sweep].

    For example, if [keyboardEvent] is in the method list with a value of 100, you know that the player was doing some internal action related to that event at least 100 times during your interaction period.

    The following table describes the internal Flash Player actions that appear in profiling data:

    Action

    Description

    		 
    [generate]

    The just-in-time (JIT) compiler generates AS3 machine code.

    		 
    [mark]

    Flash Player marks live objects for garbage collection.

    		 
    [newclass]

    Flash Player is defining a class. Usually, this occurs at startup but a new class can be loaded at any time.

    		 
    [pre-render]

    Flash Player prepares to render objects (including the geometry calculations and display list traversal that happens before rendering).

    		 
    [reap]

    Flash Player reclaims DRC (deferred reference counting) objects.

    		 
    [render]

    Flash Player renders objects in the display list (pixel by pixel).

    		 
    [sweep]

    Flash Player reclaims memory of unmarked objects.

    		 
    [verify]

    The JIT compiler performs ActionScript 3.0 bytecode verification.

    		 
    [event_typeEvent]

    Flash Player dispatches the specified event.

    You can use this information to help you identify performance issues. For example, if you see many entries for [mark] and [sweep], you can assume that there are many objects being created and then marked for garbage collection. By comparing these numbers across different performance profiles, you can see whether changes that you make are effective.

    To view data about these internal actions, you view a performance profile in the Performance Profile view or a memory profile in the Allocation Trace view. For more information, see Performance Profile view and Allocation Trace view.

    Additional resources

    The profiler alone does not improve the size, speed, and perceived performance of your application. After you use the profiler to identify the problem methods and classes, see the following resources in the Flex documentation for help in improving your application: