Using the Flash Builder profiler

About the Flash Builder profiler
Profiler toolbar
Start, stop, and resume the profiler
Save and load profiling data
Set profiler preferences
Profile external applications
Garbage collection
Identify problem areas

Important: Flash Builder 4.7 lets you profile ActionScript applications using Adobe® Scout. Adobe Scout is the next-generation profiling tool for Adobe Flash Player and Adobe AIR. It works out of the box with release applications on desktop, mobile, and in the browser. To learn more about Adobe Scout, and the differences between Adobe Scout and the Flash Builder profiler, see Using Adobe Scout with Flash Builder.

To get started with Adobe Scout and learn more, see the following:

About the Flash Builder profiler

The Flash Builder profiler requires Flash Player version 9.0.124 or later. You can profile applications that were compiled for Flex 2, Flex 2.0.1, Flex 3, and later versions of Flex. You can use the profiler to profile ActionScript 3.0 applications that were built with Flash Authoring, as well as desktop applications that run on Adobe AIR.

The profiler requires debugging information in the application that you are profiling. When you compile an application and launch the profiler, Flash Builder includes the debugging information in the application by default. You can explicitly include debugging information in an application by setting the debug compiler option to true. If you export an application by using the Export Release Build option, the application does not contain debugging information in it.

Profiler toolbar

The following table describes the buttons in the profiler toolbar:

Button	Name	Description
	Resume	Resumes the profiling session. This option is enabled only when an application name is selected and is currently suspended.
	Suspend	Suspends the profiling session. This option is enabled only when an application name is selected and is currently running.
	Terminate	Terminates the profiling session. This option is enabled only when an application name is selected and it has not been already terminated.
	Run Garbage Collector	Instructs Flash Player to run garbage collection. This option is enabled only when an application name is selected and the application is currently running. For more information about garbage collection, see Garbage collection.
	Take Memory Snapshot	Stores the memory usage of an application so that you can examine it or compare it to other snapshots. This option is enabled only when an application name is selected and that application is currently running and when you select Enable Memory Profiling in the launch dialog box. The profiler adds new memory snapshots as children of the selected application in the Profile view. To open the new memory snapshot in the Memory Snapshot view, double-click the memory snapshot entry. Garbage collection occurs implicitly before memory snapshots are recorded. In other words, clicking the Take Memory Snapshot button is the equivalent of clicking the Run Garbage Collection button and then clicking the Take Memory Snapshot button. For more information about memory snapshots, see Memory Snapshot view.
	Find Loitering Objects	Compares two memory snapshots in the Loitering Objects view. This option is enabled only when two memory snapshots are selected and when you selected Enable Memory Profiling in the launch dialog box. For more information about the Loitering Objects view, see Loitering Objects view.
	View Allocation Trace	Compares the methods between two memory snapshots in the Allocation Trace view. This option is enabled only when two memory snapshots are selected, and when you select Enable Memory Profiling in the launch dialog box. For more information about the Allocation Trace view, see Allocation Trace view.
	Reset Performance Data	Clears the performance profiling data. This option is enabled only when an application name is selected and the application is running and when you select Enable Performance Profiling in the launch dialog box. You typically click this button, interact with your application, and then click the Capture Performance Profile button to get a performance snapshot of the application from the time you reset the data. For more information about the Performance Profile view, see Performance Profile view.
	Capture Performance Profile	Stores a new performance snapshot as a child of the selected application. This option is enabled only when an application name is selected and the application is running and when you select Enable Performance Profiling in the launch dialog box. To open the Performance Profile view, double-click the performance snapshot entry. For more information about the Performance Profile view, see Performance Profile view.
	Delete	Removes the selected snapshot’s data from memory. Clicking this button also removes the application from the profile view, if the application has been terminated. This option is enabled only when a performance or memory snapshot is selected.
n/a	Save	Saves profiling data to disk. The Save option is available from the Profiler view menu. This option is enabled only when an application name is selected.

Some views in the profiler, such as Method Statistics and Object Statistics, have navigation buttons that you use to traverse the stack or change the view. The following table describes the navigation buttons in these profiler views:

Button	Name	Description
	Back	Shows all the methods that you traversed from the first selected method to the currently displaying method.
	Forward	Shows the currently displayed method and the methods that lead to the currently selected method. This item is enabled after you move backward.
	Home	Displays the first selected method.
	Open Source File	Opens a source editor that shows the source code of the selected method.
	Filters	Lets you control which methods you want to include in the table. For more information, see Profiler filters.
	Show/Hide Zero Time Methods	Shows or hides methods that have a time of 0.00 in the average time column, which is a result of not showing up in any samples.

Start, stop, and resume the profiler

You can profile applications that you are currently developing in Flash Builder. Flash Builder includes debugging information when it compiles and runs an application during a profiling session. You can also profile external applications that you are not currently developing in Flash Builder but whose SWF file is available with a URL or on the file system. To profile an application, the application’s SWF file must include the debugging information. For more information, see Profile external applications.

Start profiling an application

Close all instances of your browser.
Open your application in Flash Builder.
Click the Profile application_name button in the main toolbar. Flash Builder prompts you to close all instances of your browsers, if you have not already done so.
Click OK. Flash Builder compiles the application and launches it in a separate browser window. Flash Builder also displays the Configure Profiler dialog box.

Select the options in the Configure Profiler dialog box and click Resume. To profile an application, select the Enable Memory Profiling option or the Enable Performance Profiling option. You can select both options when profiling an application.

The following table describes the options:

Setting	Description
Connected From	Shows you the server that you are launching the application from. If the application is running on the same computer as the profiler, this value is localhost. You cannot change this value. However, you can profile an application that is running on a separate computer. See Profile external applications.
Application	Shows you which application you are about to profile. You cannot change this value.
Enable Memory Profiling	Instructs the profiler to collect memory data. Use this option to detect memory leaks or find excessive object creation. If you are doing performance profiling, you can deselect this option. By default, Enable Memory Profiling is selected.
Watch Live Memory Data	Instructs the profiler to display memory data in the Live Objects view while profiling. This is not required for doing either memory or performance profiling. You can select this option only if you selected Enable Memory Profiling. By default, Watch Live Memory Data is selected.
Generate Object Allocation Stack Traces	Instructs the profiler to capture a stack trace each time a new object is created. Enabling this option slows down the profiling experience. Typically, you select this option only when necessary. This option is only available when you select Enable Memory Profiling. By default, Generate Object Allocation Stack Traces is not selected. If you do not select this option, you cannot view allocation trace information in the Object References view or in the Allocation Trace view.
Enable Performance Profiling	Instructs the profiler to collect stack trace data at the sampling intervals. Use these samples to determine where your application spends the bulk of the execution time. If you are doing memory profiling, you can deselect this option. By default, Enable Performance Profiling is selected.

You can change the default values of these options by changing the profiling preferences. For more information, see Set profiler preferences.

You can now start interacting with your application and examining the profiler data.

Profile an application on Windows 8

To profile an application on Windows 8, see this Tech Article.

Pause and resume profiling an application

After you have started the profiler, you can pause and restart applications in the Profile view. You select an application and then select the action you want to perform on that application. The following example shows you the Profile view with multiple applications. One application is currently running while other applications have been terminated.

Stop profiling an application

Select the application in the Profile view.
Click the Terminate button to end the profiling session manually. Doing so does not close the browser or kill the Player process.
To return to the Flex Development perspective, select Flex Development from the perspective drop-down list. You can also change perspectives by selecting Control+F8 on Windows.

Save and load profiling data

After you run the profiler, you can save the data to compare a snapshot from the current profiling session with a snapshot you take after you change your code. Doing so helps you determine if you identified the right problem areas and if your changes are improving the performance and memory usage of your application.

When you save profiling data, you save all the application data in that profile. This data includes all performance profiles, memory snapshots, and allocation traces. Flash Builder writes this information to a group of binary files in the location that you specify.

Save profiling data

Select the application in the Profile view.
Open the drop-down list in the Profile view and select Save. The Browser for Folder dialog box appears.
Choose a location to save the profile data and click OK. Create a different folder for each set of profiling data that you want to save. If you choose the same folder, the new data overwrites the old data.

Retrieve saved profiling data

Select the Saved Profiling Data view.
Click the Open button. The Browser for Folder dialog box appears.
Navigate to the folder that contains your application’s profile data and click OK. Flash Builder displays the available profiling data in the Saved Profiling Data view. You cannot resume the application in this view, but you can view the memory snapshots, performance profile, or other data that you saved.

You cannot delete saved application data from within Flash Builder.

Delete profiling data

Select the snapshot from the application in the Profile view.
Click the Delete button.

Set profiler preferences

You can set some profiler preferences so that your settings are applied to all profiling sessions. You can use these settings to define the Flash Player/browser that you use to profile the application in, as well as define the default filters and the port number that the application is available on, if the profiled application is running on a server.

Set Flash Builder preferences for multiple profiling sessions

Open the Preferences dialog and select Flash Builder > Profiler.

Select the options under the Profiler menu to navigate to the various options. The following table describes the preferences you can set:

Menu Selection	Description
Profiler	Lets you select the default profiling method. Select the options to enable or disable memory profiling and performance profiling.
Connections	Lets you define the port number that Flash Builder listens to the profiled application on. The default port number is 9999. You cannot change the port to 7935, because that port is used by the debugger.
Exclusion Filters	Lets you define the default packages that are excluded from the profiler views. For more information on using filters, see Profiler filters.
Inclusion Filters	Lets you defines the default packages that are included in the profiler views. All other packages are excluded. For more information on using filters, see Profiler filters.
Player/Browser	Lets you define the location of the Flash Player executable and browser executable that Flash Builder uses to run your profiled application.

Profile external applications

In addition to profiling applications that you are developing in Flash Builder, you can profile external applications. External applications can be SWF files located anywhere that is accessible. This includes applications that are located on a remote web server or an application that is on your local file system.

For the SWF file, you can specify either a URL or a file system location. If you specify a URL, Flash Builder launches the application’s SWF file within the default browser. The browser must be using the debugger version of Flash Player to successfully profile the application.

If you specify a file system location for the SWF file, Flash Builder opens the application within the debugger version of the stand-alone Flash Player. In general, use a URL to request the file. Running applications in the stand-alone version of Flash Player can produce unexpected results, especially if your application uses remote services or network calls.

Profile an external application

Change to the Flash Profiling perspective.
Select Profile > Profile External Application. The Profile External Application dialog box appears.
Select the Launch the Selected Application option (the default) and click the New button. The Add an Application dialog box appears.

You can also manually launch the application by selecting the Launch the Application Manually Outside Flash Builder option.
Enter the location of the SWF file and click OK, or click the Browse button and locate your application on your file system.
Click the Launch button. If you specified a URL for the location of the application, Flash Builder launches the application within the default browser. If you specified a file system location for the application, Flash Builder opens the application in the stand-alone version of Flash Player.

If you specified a SWF file that was not compiled with debugging information, Flash Builder returns an error. Recompile the application with the debug compiler option set to true and launch it again.

Garbage collection

Garbage collection is the act of removing objects that are no longer needed from memory. Memory used by instances that no longer have any references to them should be deallocated during this process.

Flash Player performs garbage collection as necessary during an application’s life cycle. Unreferencing an object does not trigger garbage collection. So, when you remove all references to an object, the garbage collector does not necessarily deallocate the memory for that object. That object becomes a candidate for garbage collection.

Clicking the Run Garbage Collector button does not guarantee that all objects that are eligible for garbage collection are garbage collected. Garbage collection is typically triggered by the allocation of memory for new resources. When new resources require memory that is not available in the current allocation, the garbage collector runs and frees up memory that has been marked for deallocation. As a result, even if you remove all references to it, it might not be immediately garbage collected, but likely will be garbage collected when other instances are created and used. If an application is idle, you can watch its memory allocation. Even though there can be objects that are marked for collection, an idle application’s memory usage typically does not change until you start interacting with it.

Flash Player allocates memory in blocks of many bytes, and not one byte at a time. If part of a block has been marked for garbage collection, but other parts of the block have not been marked, the block is not freed. The garbage collector attempts to combine unused portions of memory blocks into larger blocks that can be freed, but this is not guaranteed to occur in every pass of the garbage collector.

Garbage collection occurs implicitly before memory snapshots are recorded. In other words, clicking the Take Memory Snapshot button is the equivalent of clicking the Run Garbage Collector button and then clicking the Take Memory Snapshot button.

Run garbage collection while profiling your application

Select the application in the Profile view, and click the Run Garbage Collector button.

You analyze the garbage collector’s effectiveness by comparing two memory snapshots before and after garbage collection occurs.

Identify problem areas

You can use various techniques to identify problem areas in your applications by using the profiler.

Locate memory leaks

One of the most common problems you face in application development is memory leaks. Memory leaks often take the form of objects that were created within a period but not garbage collected.

One way to identify memory leaks is to look at the number of references to an object in the Instances table in the Object References view. You can generally ignore references from document properties and bindings, and look for unexpected or unusual references, especially objects that are not children of the object. For more information, see Object References view.

You can also examine paths to instances of an object to determine if a path has a back-reference to the garbage collector (GC Root). An instance that was expected to be released, but has references to GC Root, indicates a memory leak. In these cases, modify your application code so references to GC Root are removed. An instance that has no references to GC Root is ready for garbage collection. Flash Player eventually frees this memory.

Another way to locate memory leaks is to compare two memory snapshots in the Loitering Objects view to determine which objects are still in memory after a particular series of events.

Common ways to clean up memory links are to use the disconnect(), clearInterval(), and removeEventListener() methods.

Find a back-reference to GC Root for an instance

Create a memory snapshot.

See Create and view a memory snapshot.
Specify the number of back-reference paths to find.

From the Memory Snapshot view, specify the maximum number of paths to find, or select Show All Back-Reference Paths.
Double-click a class in the memory snapshot to open the Object Reference view.
Expand the listed paths to and examine if there is a back-reference to GC Root.

Find loitering objects

Create two memory snapshots.

See Create and view a memory snapshot.
Select the two memory snapshots to compare.

Note: If you have more than two memory snapshots, you cannot select a third one. You can compare only two memory snapshots at one time.
Click the Find Loitering Objects button.

Loitering Objects view shows you potential memory leaks. The Instances and Memory columns show the differences between the number of instances of a class and the amount of memory consumed by those instances during the interval between one snapshot and the next. If you see a class that you did not expect to be created during that time, or a class that you expected to be destroyed during that time, investigate your application to see if it is the source of a memory leak.
To determine how an object in the Find Loitering Objects view was instantiated, double-click the object in the view. The Object References view shows you the stack trace for each instance that you selected.

One approach to identifying a memory leak is to first find a discrete set of steps that you can do over and over again with your application, where memory usage continues to grow. It is important to do that set of steps at least once in your application before taking the initial memory snapshot so that any cached objects or other instances are included in that snapshot.

Then you perform that set of steps in your application a particular number of times—3, 7, or some other prime number—and take the second memory snapshot to compare with the initial snapshot. In the Find Loitering Objects view, you might find loitering objects that have a multiple of 3 or 7 instances. Those objects are probably leaked objects. You double-click the classes to see the stack traces for each of the instances.

Another approach is to repeat the sequence of steps over a long period and wait until the memory usage reaches a maximum. If it does not increase after that, there is no memory leak for that set of steps.

Common sources of memory leaks include lingering event listeners. You can use the removeEventListener() method to remove event listeners that are no longer used. For more information, see Object creation and destruction in Using Flex 4.6.

Analyze execution times

By analyzing the execution times of methods and the amount of memory allocated during those method calls, you can determine where performance bottlenecks occur.

This is especially useful if you can identify the execution time of methods that are called many times, rather than methods that are rarely called.

Determine frequency of method calls

Start a profiling session and ensure that you enable performance profiling when configuring the profiler on the startup screen.
Select your application in the Profile view.
Interact with your application until you reach the point where you want to start analyzing the number of method calls. To see how many times a method was called from when the application started up, do not interact with the application.
Click the Reset Performance Data button. This clears all performance data so that the next performance profile includes any data from only this point forward.
Interact with your application until you reach the point where you check the number of method calls since you reset the performance data.
Click the Capture Performance Profile button.
Double-click the performance profile in the Profile view.
In the Performance Profile view, sort the data by the Method column and find your method in the list.

The value in the Calls column is the number of times that method was called during this sampling interval. This is the time between when you clicked the Reset Performance Data button and when you clicked the Capture Performance Profile button.

Examine the values in the Cumulative Time, Self Time, Avg. Cumulative Time, and Avg. Self Time columns of the Performance Profile view. These show you the execution time of the methods.

Compare the time each method takes to execute against the time that all the methods that are called by a particular method take to execute. In general, if a method’s self-time or average self-time are high, or high compared to other methods, look more closely at how the method is implemented and try to reduce the execution time.

Similarly, if a method’s self-time or average self-time are low, but the cumulative time or average cumulative time are high, look at the methods that this method calls to find the bottlenecks.

Locate excessive object allocation

One way to identify trouble areas in an application is to find out where you might be creating an excessive number of objects. Creating an instance of an object can be an expensive operation, especially if that object is in the display list. Adding an object to the display list can result in many calls to style and layout methods, which can slow down an application. In some cases, you can refactor your code to reduce the number of objects created.

After you determine whether there are objects that are being created unnecessarily, decide whether it is reasonable or worthwhile to reduce the number of instances of that class. For example, you could find out how large the objects are, because larger objects generally have the greatest potential to be optimized.

To find out which objects are being created in large numbers, you compare memory snapshots of the application at two points in time.

View the number of instances of a specific class

Start a profiling session and ensure that you enable memory profiling when configuring the profiler on the startup screen.
Interact with your application until you reach the place to take a memory snapshot.
Click the Take Memory Snapshot button. The profiler adds a new memory snapshot to the application list in the Profile view.
Open the memory snapshot by double-clicking it in the Profile view.
To view the number of instances of a particular class, and how much memory those instances use, sort by the Class column and find your class in that column. You can also sort by the other columns to quickly identify the objects that take up the most memory or the objects with the most instances. In most cases, Strings are the class with the most instances and the most memory usage.

For more information about the Memory Snapshot view, see Memory Snapshot view.

Locate instances of excessive object allocation

Start a profiling session and ensure that you enable memory profiling when configuring the profiler on the startup screen.
Interact with your application until you reach the first place to take a memory snapshot.
Click the Take Memory Snapshot button.

The profiler saves the memory snapshot in the Profile view, and marks the snapshot with a timestamp.
Interact with your application until you reach the second place to take a memory snapshot.
Click the Take Memory Snapshot button again.

The profiler saves the second memory snapshot in the Profile view, and marks the snapshot with a timestamp.
Select the two memory snapshots to compare.

Note: If you have more than two memory snapshots, you cannot select a third one. You can compare only two at a time.
Click the View Allocation Trace button.

The Allocation Trace view shows which methods were called between the two snapshots and how much memory was consumed during those method calls. See Allocation Trace view.