Flex Camp Boston 2007: Using the Flex Profiler
Rough draft notes
Paul Reilly is speaking about Using the Flex Profiler
Memory profiling lets you look at objects being created, take snapshots and compare them. Performance profiling allows snapshots for looking at cumulative and internal time.
Memory profiling is light-weight compared to performance profiling when configuring the settings.
Profiler runs at the end of the frame which is why there maybe delays in getting updates to the profiler in Flex Builder.
Memory leak detection work flow: select app and take memory snapshot, switch to application and perform an operation, then take a second memory snapshot. Select both snapshots and view loitering objects. Can look at back references to determine who is holding onto something. Most common memory issue is strong references with event listeners. Can either remove the listeners manually or in most cases it is possible to use weak references. Best to reset profile information at the start unless you want to focus on initialization phase.
Can profile any external SWF, in general this is done with the standalone Flash player. Filtering of artificial functions isn't there yet (such as reaping, mouse handling, etc.) but you can change what gets shown such as removing the mx.* filter.
With performance profiling you can look at callers and callees to see how a function is being used. Important to remove filters so that mx.* abd flash.* are included in the list unless you want to focus only on your code.
Profiler supports debugging capabilities. mm.cfg file can be used to control settings. flashlog.txt doesn't get created if using a release version, good way to test that you are using a debug version of the player.
ErrorReportingEnable=1
TraceOutputFileEnable=1
PreloadSwf=ProfilerAgent.swf?debug=true
Additional information outputted into flashlog.txt that shows what the profiler is doing.
mm.cfg is only read once so if you are using multiple tabs in a browser it is only read the first time.
Runtime exceptions or infinite loops will cause the profiler to not work very well.
Taking a memory snapshot implicitly makes a garbage collection call.
Internally the player is using a stack trace (once every millisecond) for performance timing, new object samples (every time an object is create), and delete object samples (every time the GC collects an object). flash.sampling package includes way to get at the same information if you want to roll your own profiler.
DisplayObjectContainer and EventDispatcher are classes that are hard to get the internals of and there are back door methods to get access to data useful for profiling.
Profiler is sample based (not trace based), provides quicker profiling but not as detailed.
When is the best time to take snapshots? Look at overall memory chart to see where the issue might be. Try to narrow down operation in application that causes memory increase. Then start taking snapshots before and after performing that application.
Can you programmatically trigger a snapshot? Not at this time but create an enhancement bug and vote for it.
It is possible to profile AIR applications.