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.

    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.