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 very 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.

About the 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.

About internal player actions

Typically, the profiler records that Flash Player was executing methods of a particular class during the sampling snapshot, but sometimes it 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:

You can use this information to help you identify performance issues. For example, if you see a large number of entries for [mark] and [sweep], you can assume that there are a large number of 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 have any effect.

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 Using the Performance Profile view and Using the Allocation Trace view.