About the profiler views

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:

View full size graphic

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.

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.

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:

View full size graphic

The following table describes the columns in the Instances table:

o.i = myButton.label;

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:

View full size graphic

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.

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:

View full size graphic

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.

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:

View full size graphic

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:

View full size graphic

The following table describes the fields in the Callee Instances table of the Object Statistics 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:

View full size graphic

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

Column	Description
Method	The name of the method and the class to which the method belongs. Internal actions executed by Flash Player appear as entries in brackets; for example, [mark] and [sweep]. You cannot change the behavior of these internal actions, but you can use the information about them to aid your profiling and optimization efforts. For more information on these actions, see How the Flex profiler works.
Package	The package that the class is in. If the class is not in a package, then the value of this field is the file name that the class is in. The number following the dollar sign is a unique ID for that class. If the Package field is empty, the class is in the global package or the unnamed package.
Calls	The number of times the method was called during the interaction period. If one method is called a disproportionately large number of times compared to other methods, then you can look to optimizing that method so that the execution time is reduced.
Cumulative Time	The total amount of time, in milliseconds, that all calls to this method, and all calls to subsequent methods, took to execute during the interaction period.
Self Time	The amount of time, in milliseconds, that all calls to this method took to execute during the interaction period.
Avg. Cumulative Time	The average amount of time, in milliseconds, that all calls to this method, and calls to subsequent methods, took to execute during the interaction period.
Avg. Self Time	The average amount of time, in milliseconds, that this method took to execute during the profiling period.

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.

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:

View full size graphic

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

Column	Description
Method	The methods that called the method that appears in the summary at the top of this view. If this list is empty, the target method was not called by any methods that are not filtered out.
Package	The package that each class is in. If the class is not in a package, then the value of this field is the file name that the class is in. The number following the dollar sign is a unique ID for that class. If the Package field is empty, the class is in the global package or the unnamed package.
Cumulative Time	The amount of time, in milliseconds, that each calling method, and all subsequent methods, spent executing.
Self Time	The amount of time, in milliseconds, that each calling method spent executing. This does not include methods called by subsequent methods.

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

Column	Description
Method	The methods that were called by the method that is shown in the summary at the top of this view. If this list is empty, then the target method was not called by any methods that are not filtered out.
Package	The package that each class is in. If the class is not in a package, then the value of this field is the file name that the class is in. The number following the dollar sign is a unique ID for that class. If the Package field is empty, the class is in the global package or the unnamed package.
Cumulative Time	The amount of time, in milliseconds, that each called method, and all subsequent methods, spent executing.
Self Time	The amount of time, in milliseconds, that each called method spent executing. This does not include methods called by subsequent methods.

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.

Note: The cumulative time minus the self-time in this view will not always equal the cumulative time of the callers. That is because if you drill up to a caller, then the cumulative time will be the self-time of that caller plus all chains from which the original method was called, but not other callees.

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.

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:

View full size graphic

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

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

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:

View full size graphic

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.