- Flash Player Memory Use
- Memory Profiling a Flex Application
- Performance Profiling a Flex Application
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Performance Profiling a Flex Application
Performance profiling is used to find aspects of your application that are unresponsive, or where performance can be improved. When profiling for performance, generally you’re looking for methods that are executed very frequently, or methods that take a long time whenever they’re executed. The combination of those two factors usually provides a good indication of where your time should be spent in optimizing or potentially refactoring.
In this exercise, we’ll continue with the same poorly designed sample project. Although you’ve already fixed the major memory issue, performance issues remain. Using the Flex Builder Profiler, you’ll identify one of the slowest portions of the application and optimize it. Then you’ll verify the results with the Profiler.
Profiling the ProfilerTest Application
In this exercise, you’ll use the performance profiling capabilities of the Flex Profiler to identify the methods and objects responsible for the slow response of the ProfilerTest application. You’ll capture a performance profile and review it to identify methods taking a disproportionate amount of time to execute.
- Click the Profile Application button (immediately to the right of the
Debug button).
The application begins launching, but then focus returns to the Flex Builder window and a Configure Profiler window appears.
- Make sure that only "Enable performance profiling" is selected, as shown in Figure 14.
- Click Resume. The Eclipse perspective changes to Flex Profiling.
When you’re only capturing performance metrics, the Profiling perspective is rather boring, as Figure 15 shows. Nothing actually happens here until we’re ready to dive into performance profiles.
- Select the running application, and click the icon that looks like an
eraser to reset the performance statistics.
In this case, we’re not trying to gauge startup time, so we’re resetting our performance statistics after the application has started but before we interact with it.
- Switch to your web browser and navigate through each of the six product categories. Be sure to wait for the previous category to load completely before you click the next category.
- Switch back to the Flex Profiler and select the running application.
- To capture a performance profile, click the icon that shows a clock and a
pair of glasses.
A performance profile appears under the running application, much as the memory profile did in the previous section.
- Click the red stop icon to stop profiling the running application. Then close your web browser.
- Double-click the performance profile to open the Performance Profile
view.
The Performance Profile view shows the method and package along with other crucial information:
- Calls shows the number of calls to this method during the capture.
- Cumulative Time shows the cumulative time spent in the calls to this method and any subsequent methods called within this method.
- Self Time shows the cumulative time spent in this method, but not subsequent method calls within this method.
- Avg. Cumulative and Avg. Self show the averages of each of the previous time types.
- Click the Cumulative Time column to sort from longest to shortest (see Figure 16).
)
)
)
The top three items are the completeHandler for the HTTP Response, the handleDataResult method of ProfilerTest, and the ImageDisplay’s initialize method. However, the Self Time for each of these methods is almost nonexistent. The returned data from the server causes the application to create a new instance of the ImageDisplay class, which is far from optimized. It would seem that creating those ImageDisplay classes is the source of your performance loss.
Fixing the ProfilerTest Class
In this exercise, you’ll address the source of the largest performance issue identified in the preceding exercise: creation of ImageDisplay instances. You’ll use a property of the Repeater class to limit object re-creation and significantly increase the responsiveness of the application.
- Switch back to the Flex Development perspective in Flex Builder.
- Open the ProfilerTest.mxml class.
- Find the repeater in the application on line 65.
- Repeaters have a property called recycleChildren. Set it to
true.
When recycleChildren is set to true, the repeater reuses the children it already created, instead of creating new ones. As you saw in the previous example, right now you create three new children every time you click a category. Reusing those children will save a significant amount of time.
- Save the ProfilerTest.mxml file, and profile your application again using the steps in the preceding exercise. You’ll see a significant reduction in time for these methods and an improvement in performance.
Ultimately, performance profiling is about optimizing the items that cost the most amount of time. It’s an iterative process that continues until the application performs as required.
The ProfilerTest application can be optimized significantly. Right now, it’s extremely slow when laying out and organizing its children, and lacks any intelligence when reloading data that has already been loaded once. Continuing to optimize an application like this is a great exercise to learn these tools.