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.
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
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 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],
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:
The just-in-time (JIT) compiler generates
AS3 machine code.
Flash Player marks live objects for garbage
Flash Player is defining a class. Usually,
this occurs at startup but a new class can be loaded at any time.
Flash Player prepares to render objects
(including the geometry calculations and display list traversal
that happens before rendering).
Flash Player reclaims DRC (deferred reference
Flash Player renders objects in the display
list (pixel by pixel).
Flash Player reclaims memory of unmarked
The JIT compiler performs ActionScript 3.0
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.
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: