Flex 3:Feature Introductions: Performance and Memory Profiling
From Adobe Labs
| Table of contents |
Introduction
One of the exciting new features of Flex Builder 3 is the Profiler. In this write-up, I'll be explaining how to get started with the Profiler and how to accomplish some common tasks. Along the way, I will also be pointing out some gotchas and bugs to watch out for.
Getting Started
To get started with profiling, look for the profiler button 
in the Flex Development perspective's toolbar:
Clicking on the profiler button , should
launch the application using the default browser. You can configure
profiling to use IE, Firefox, or the standalone Flash Player.
After launching, the Profiler will pause the application:
Then the Profiler will display a "Profiler Agent" configuration dialog:
In the configuration dialog, you should see four check boxes. The
first, "Enable memory profiling" will cause the Profiler Agent to
collection information each time an object is created and garbage
collected. This information is useful when trying to find potential
memory leaks and when trying to find excessive object creation.
The second check box, "Watch live memory data", instructs Flex Builder to display the "Live Objects" panel. This panel shows what classes have been instantiated, how many have been created, how many are in the heap, how much memory they have taken up and how much memory the active objects are taking up.
The third check box, "Generate object allocation stacktraces", will cause a stack trace to be captured each time a new object is created. This can cause profiling to run slower and use more memory, so we recommend using it only as needed.
The last check box, "Enable performance profiling" will cause the Profiler to collect a sample, essentially a stack trace, at regular intervals. These samples can be used to determine where the bulk of the execution time in your application is spent. Sampling allows you to profile without noticeably slowing down the application.
For now, we'll just leave the defaults and click "Resume".
Profile Panel
This panel shows each of the applications currently being profiled and the status, Running or Terminated. It's possible to analyze exiting memory and performance snapshots after the application has been terminated.
Here are the Profile panel's toolbar buttons and what they are used for:
Used to resume an application.
Used to suspend an application.
Used to terminate profiling.
The application should continue to run.
This forces a garbage collection. A
garbage collection is automatically forced before each memory
snapshot.
This takes a memory snapshot.
This finds potential memory leaks. Two memory
snapshots must be selected for this button to be enabled.
This shows memory use by function.
This resets the starting point for the next performance snapshot.
This takes a performance snapshot.
Deletes the currently selected application or snapshot.
Displays the menu, which includes the
"Profile External Application" and
"Save" menu items.
- Displays the launch dialog, which can be used to profile
external applications.
Live Objects Panel
This panel shows the class name and package name of each object which has been instantiated since the application started up. The package name will be empty for top level classes, like SimpleButton, and built in classes, like String and Class. Also shown is the cumulative instances, currently live instances, cumulative memory use, and current memory use. As objects are garbage collected the number of instances and memory use should go down, but the cumulative instances and cumulative memory use should continue to go up.
Use the 
button to bring up the Filters dialog:
By default all Flash classes (top level classes, like String, and classes in the flash.* package) and Flex classes (classes in the mx.* package) are filtered out. I often find it useful to remove these filters. The Profiler will remember your choices, so you won't have to modify the filters the next time you run the application.
Memory Snapshot Panel
To take a memory snapshot, select an application in the Profile panel:
Then click the memory snapshot button 
in the toolbar. After that you should
see something like this:
After that, double click on the memory snapshot node. This should bring up a Memory Snapshot panel:
Loitering Objects Panel
To use the "Loitering Objects" panel, you need to start by taking an initial memory snapshot, see "Memory Snapshot" panel. After that you will want perform some actions, which you suspect might be causing a memory leak, in the application. Next, you need to take another memory snapshot. Here is what that should look like:
Next select the two memory snapshots by selecting one memory snapshot,
then hold down the Ctrl key and select the other memory snapshots:
Then click on the "Loitering Objects" button 
, which should have become enabled
after selecting two memory snapshots. This should bring up the
Loitering Objects panel:
Rows in the "Loitering Objects" panel represent potential memory leaks. It's likely that some of the objects, which were created between the memory snapshots and which were not garbage collected, are expected. Any that aren't expected, are memory leaks. You'll have to investigate your application to determine which are unexpected.
Object References Panel
Doubling clicking on a row in "Loitering Objects" panel should bring up the "Object Referencs" panel:
This panel is use to walk backwards up the heap graph to find the object or objects, which are keeping the leaked object from being garbage collected. The "Allocation Trace" side panel will only show allocation traces if they were enabled, see the "Configuration Dialog".
Allocation Trace Panel
Clicking on the allocation trace button 
brings up the Allocation Trace panel, which shows memory use by
function:
This panel is useful in determining which functions use the most memory. These functions are the places to look if you want to reduce memory use or excessive object creation.
Note the "Generate object allocation stacktraces" check box must be checked for this panel to function. See <A HREF="#Getting Started">Getting Started</A>.
Performance Snapshot Panel
To take a performance snapshot, select an application in the Profile Panel:
Then click the memory snapshot button 
in the toolbar. After that you should see something like this:
After that, double click on the performance snapshot node. This should bring up a Performance Snapshot Panel:
Method Statistics Panel
To open the Method Statistics Panel, double click on a row in the <A HREF="#Performance Snapshot Panel"/>Performance Snapshot Panel</A>:
You can drill down on a function by double clicking on a row in the Callers or Callees table:
Launch Dialog
The launch dialog can be used to profile applications outside Flex
Builder. To open the Launch Dialog click on the menu icon 
and click on the Launch Dialog icon . It should look like this:
To launch an application, select it and click the "Launch" button. Alternatively, click the "Launch the application manually outside Flex Builder" check box. Then open the application using a browser or the standalone Flash Player manually.
Player Launching
When profiling, the default for Flex Builder is to launch your application using the default browser:
You can explicitly specify the standalone player or browser using the
Flex Player/Browser preferences:
Saving and Loading Profiling Data
New for beta 2, profiling data can be saved and reloaded. To save a
profiling session use the 
"Save" option in the menu:
This should prompt for a directory. The profiling data will be saved
as a set of data files, which include a string table file, a samples
file, an info file, one counts file per performance snapshot, and one
members file per memory snapshot. These files are written using Java
object serialization and are not expected to be human readable.
To load a saved profiling session, select the "Saved Profiling Data"
panel and click 
"Open". This will prompt for a
directory where a profiling session has previously been saved. After
loading a saved profiling session, existing memory and performance
snapshots can be viewed, but new snapshots cannot be created.
FAQ
1. What are the bracketed functions, like [reap],
[newclass], [mouseEvent], [enterFrameEvent], etc?
These are synthetic functions that the Flash Player inserts into
stack traces to help explain what is going on when AS3 code is not
being executed.
2. What is global$init?
This is the script init which is code the compiler
generates to define a class and add it to the global object.
3. Can the Profiler be used with Flex 2.0 and Flex 2.0.1 applications?
Yes.
4. Can the Profiler be used with Flash Authoring AS3 based applications?
Yes.
5. Can the Profiler be used with AS2 applications?
No.
6. Is Adobe AIR profiling supported?
New for beta 2, yes!
7. Is profiling production SWF's supported?
No. Only debug SWF's work with the Profiler.
8. Is profiling increase time precision planned?
Known Issues
- SDK-12687
Profiling external AIR applications on Mac does not work. The
workaround is to create or edit the mm.cfg file in
/Library/Application Support/Macromedia directory by adding:
PreloadSwf=<FB Workspace>/Flex Builder 3/.metadata/.plugins/com.adobe.flash.profiler/ProfilerAgent.swf?host=localhost&port=9999This should be commented out using a '#' or removed when profiling is done.
