The Flex profiler is made up of several views (or panels) that present profiling data in different ways. The following table describes each of these views:

Viewing information in the Live Objects view

The Live Objects view displays information about the classes that the current application uses. This view shows which classes are instantiated, how many were created, how many are in memory, and how much memory the active objects are taking up.

The profiler updates the data in the Live Objects view continually while you profile the application. You do not have to refresh the view or keep focus on it to update the data.

To use the Live Objects view, you must enable memory profiling when you start the profiler. This is the default setting. If you close the Live Objects view and want to reopen it, open the drop-down list in the Profile view and select Watch Live Objects.

The following example shows the Live Objects view:

The following table describes the columns in the Live Objects view:

You typically use the data in the Live Objects view to see how much memory is being used by objects. As objects are garbage collected, the number of instances and memory use decrease, but the cumulative instances and cumulative memory use increase. This view also tells you how memory is used while the application is running.

For more information on running and analyzing the results of garbage collection, see About garbage collection.

You limit the data in the Live Objects view by using the profiler filters. For more information, see About profiler filters.

Using the Memory Snapshot view

The Memory Snapshot view displays information about the application's objects and memory usage at a particular time. Unlike the Live Objects view, the data in the Memory Snapshot view is not continually updated.

To use the Memory Snapshot view, you must enable memory profiling when you start the profiler. This is the default setting.

Create and view a memory snapshot

1. Start a profiling session.
2. Interact with your application until you reach a point in the application's state where you want to take a memory snapshot.
3. Select the application in the Profile view.
4. Click the Take Memory Snapshot button.

   The profiler creates a memory snapshot and marks it with a timestamp. The profiler also implicitly triggers garbage collection before the memory snapshot is recorded.

5. To view the data in the memory snapshot, double-click the memory snapshot in the Profile view.

The following example shows the Memory Snapshot view:

The following table describes the columns in the Memory Snapshot view:

You typically use a memory snapshot as a starting point to determine which classes you should focus on for memory optimizations or to find memory leaks. You do this by creating multiple memory snapshots at different points in time and then comparing the differences in the Loitering Objects or Allocation Trace views.

You can save memory snapshots to compare an application's state during a different profiling session. For more information, see Saving and loading profiling data.

When you double-click a row in the Memory Snapshot view, the profiler displays the Object References view. This view displays the stack traces for the current class's instances. You view the stack traces for the current class's instances in the Object References view. For more information about the Object References view, see Using the Object References view.

You can also limit the data in the Memory Snapshot view by using the profiler filters. For more information, see About profiler filters.

Using the Object References view

The Object References view displays stack traces for classes that were instantiated in the application.

To open the Object References view, double-click a class name in the Memory Snapshot or Loitering Objects views. The Object References view displays information about the selected class's instances.

The Object References view displays data in two tables: the Instances table and the Allocation Trace table.

The Instances table lists all objects that hold references to the current object. The number in parentheses after the class name is the total number of references to the current object. You cannot view the number of forward references for an object. If no objects hold references to the specified object, then there will be no objects listed in this table. This would not normally happen because that object should have been garbage collected if it had no references.

The following example shows the Instances table in the Object References view:

The following table describes the columns in the Instances table:

The Allocation Trace table shows the stack trace for the selected instance in the Instances table. When you select an instance in the Instances table, the profiler displays the call stack for that instance in the Allocation Trace table.

The following example shows the Allocation Trace table in the Object References view:

The following table describes the columns in the Allocation Trace table:

You can only view data in this table when you enable allocation traces when you start the profiler.

You can open the source code of the selected class by double-clicking a class in this table.

Using the Allocation Trace view

The Allocation Trace view shows which methods were called between two memory snapshots and how much memory was consumed during those method calls. To open the Allocation Trace view, you select two memory snapshots, and then click the View Allocation Trace button. For information on recording a memory snapshot, see Using the Memory Snapshot view.

The result of the memory snapshot comparison is a list of methods that Flash Player executed between the two memory snapshots. For each of these methods, the profiler reports the number of objects created in that method.

You can use this information to optimize performance. After you identify methods that create an excessive number of objects, you can optimize those hot spots.

To use the Allocation Trace view, you must enable allocation traces when you start the profiler. The default is disabled.

The following example shows the Allocation Trace view:

The following table describes the columns in the Allocation Trace view:

When recording methods during sampling intervals, the profiler also records internal Flash Player actions. These actions show up in the method list in brackets and appear as [mouseEvent] or [newclass] or with similar names. For more information about internal Flash Player actions, see How the Flex profiler works.

To open the Object Statistics view, click a row in the Allocation Trace table. This view provides details about the objects that were created in the method that you selected. It also lets you drill down into the objects that were created in methods that were called from this method. For more information, see Using the Object Statistics view.

You limit the data in the Allocation Trace view by using the profiler filters. For more information, see About profiler filters.

Using the Object Statistics view

The Object Statistics view shows the performance statistics of the selected group of objects. This view helps you identify which methods call a disproportionate number of other methods. It also shows you how much memory the objects instantiated in those method calls consume. You use the Object Statistics view to identify potential memory leaks and other sources of performance problems in your application.

To access the Object Statistics view, you select two memory snapshots in the Profile view and view the comparison in the Allocation Trace view. Then you double-click a row to view the details in the Object Statistics view.

There are three sections in the view:

• A summary of the selected object's statistics, including the number of instances and amount of memory used.
• Self Instances table--A list of objects that were instantiated in the method that you selected in the Allocation Trace view. This does not include objects that were instantiated in subsequent method calls from this method. The number of objects in this list matches the number of objects specified in the Self Instances column in the Allocation Trace view.
• Callee Instances table--A list of objects that were instantiated in methods that were called by the method that you selected in the Allocation Trace view. This does not include objects that were instantiated in the method itself. The number of objects in this list matches the number of objects specified in the Cumulative Instances column in the Allocation Trace view.

The following example shows the method summary and the Self Instances and Callee Instances tables of the Object Statistics view:

The following table describes the fields in the Self Instances table in the Object Statistics view:

The following example shows the Callee Instances table of the Object Statistics view:

The following table describes the fields in the Callee Instances table of the Object Statistics view:

Using the Performance Profile view

The Performance Profile view is the primary view to use when doing performance profiling. It shows statistics such as number of calls, self-time, and cumulative time for the methods that are called during a particular sampling interval. You use this data to identify performance bottlenecks.

The process of performance profiling stores a list of methods and information about those methods that were called between the time you clear the performance data and the time you capture new data. This time difference is known as the interaction period.

To use the Performance Profile view, you must enable performance profiling when you start the profiler. This is the default setting.

Generate a performance profile

1. Start a profiling session with performance profiling enabled.
2. Interact with your application until you reach the point where you want to start profiling.
3. Click the Reset Performance Data button.
4. Interact with your application and perform the actions to profile.
5. Click the Capture Performance Profile button.

   The time difference between when you clicked Reset Performance Data and the time you clicked Capture Performance Profile is the interaction period. If you do not click the Reset Performance Data button at all, then the performance profile includes all data captured from the time the application first started.

6. Double-click the performance profile in the Profile view.

The following example shows the Performance Profile view:

The following table describes the columns in the Performance Profile view:

If you double-click a method in the Performance Profile view, Flex displays information about that method in the Method Statistics view. This lets you drill down into the call stack of a particular method. For more information, see Identifying method performance characteristics.

You limit the data in the Performance Profile view by using the profiler filters. For more information, see About profiler filters.

You can save performance profiles for later use. For more information, see Saving and loading profiling data.

Identifying method performance characteristics

The Method Statistics view shows the performance characteristics of the selected method. You typically use the Method Statistics view to identify performance bottlenecks in your application. By viewing, for example, the execution times of a method, you can see which methods take a disproportionate amount of time to run. Then you can selectively optimize those methods.

For more information, see Using the Performance Profile view.

View method details in the Method Statistics view

1. Double-click a row in the Performance Profile view or select a method in the Performance Profile view.
2. Click the Open Method Statistics button.

There are three sections in the view:

• A summary of the selected method's performance, including the number of calls, cumulative time, and self-time.
• Callers table--Details about the methods that called the selected method. In some situations, it is important to know if the selected method is being called excessively, how it is being used, and whether it is being used correctly.
• Callees table--Details about the methods that were called by the selected method.

The following example shows the method summary and the Callers and Callees tables of the Method Statistics view:

The following table describes the fields in the Callers table of the Method Statistics view:

The following table describes the fields in the Callees table of the Method Statistics view:

You can navigate the call stack while you attempt to find the performance bottlenecks by clicking the methods in either the Callers or Callees tables. If you double-click a method in these tables, the profiler displays that method's summary at the top of the Method Statistics view and then shows the callers and callees for the newly selected method in the two tables.

You can also use the Back, Forward, and Home profiler buttons to navigate the call stack.

You can limit the data in the Method Statistics view by using the profiler filters. For more information, see About profiler filters.

Using the Loitering Objects view

The Loitering Objects view shows you the differences between two memory snapshots of the application that you are profiling. The differences that this view shows are the number of instances of objects in memory and the amount of memory that those objects use. This is useful in identifying memory leaks. The time between two memory snapshots is known as the snapshot interval.

To open the Loitering Objects view, select two memory snapshots and click the Loitering Objects button. For information on recording a memory snapshot, see Using the Memory Snapshot view.

The following example shows the Loitering Objects view:

The following table describes the columns in the Loitering Objects view:

For more information on identifying memory leaks, see Locating memory leaks.

Using the Memory Usage graph

The Memory Usage graph shows you the memory used by the application that you are profiling. This value is different from the memory usage of the Flash Player and its browser. That is because this value does not include the profiler agent or the browser's memory usage. It consists only of the sum of the profiled application's live objects. As a result, if you compare the value of memory usage in this graph against the amount of memory the browser uses as shown in, for example, the Windows Task Manager, you will get very different results.

The following image shows the graph in the Memory Usage view:

The value for Current Memory is the same as the sum of the totals in the Live Objects view's Memory column, assuming that all filters are disabled.

The value for Peak Memory is the highest amount of memory that this application has used during the current profiling session.

The Memory Usage graph shows the application's memory for the last 100 seconds. You cannot configure this number, and you cannot save historical data for the chart.

If you close the Memory Usage graph and want to reopen it, click the drop-down menu button in the Profile view and select Memory Usage.