Let’s Talk About The Flex Profiler
Yeah, I know. This is a compiler blog, not a profiler blog. But I can explain…
The performance and memory profiling feature in Flex Builder Professional Edition wasn’t done by the FB development team. It was done by the Flex compiler team. Yes. I mean everything: the Eclipse plugin, user interface, profiler agent, data collection and processing!
So now you know that the compiler team was not only busy with the compiler, but also the profiler, during the Flex 3 development cycle. And that explains why I’m “eligible” to talk about the profiler here…
Those who have been closely following Flex since version 1 should notice that profiling was present in version 1 and 1.5 but absent in version 2 and 2.0.1. Why no profiler in version 2? It’s a long story. But it was a combination of poor scheduling, coordination and… well… lack of technological advances.
You may ask, what technological advances? Well, if you had used Flex 1.0 and 1.5 in the past, you should know that there was a performance profiler (http://www.adobe.com/devnet/flex/articles/profiler.html). The performance profiler in Flex 1.x was trace-based, i.e. the Player records timing data for everything that happens in the old AVM. The upside is that it captures everything. The downside is that it makes the Player run slowly and the amount of data for a short period of time (say 10 seconds) could be huge and take time to process. I’m not suggesting that the Flex 1.x performance profiler is not useful. It needs you to know roughly where to optimize. In fact, thanks to the profiler, we were able to improve Flex 1.5 framework startup performance by over 30%. Yahoo! was able to speed up their Flash/Flex-based Yahoo! Maps before the debut. But the breakthrough came when Tom Reilly added support for sample-based profiling to the latest Player…
I’m making an assumption here that you all studied statistics when you were in college and know what sampling is. If not, ask the people around you about the purpose of national presidential polls you hear these days. Same idea. Of course, I’m very sure that Tom’s stuff for identifying performance bottlenecks in your code is a lot more accurate than those national polls for predicting the next president of the United States! 🙂
Unlike traced-based, with sample-based profiling, you don’t get everything. But your application runs just as fast (or as slow) when sampling is enabled. Because it’s sampling, you don’t get a notification every time your application enters or exits a function. But you still get a pretty accurate performance profile.
So far so good, but there are some negatives. For instance, it is pretty tricky to find, given a function that is getting called excessively, the time distribution from the list of callers of that function.
Other than performance profiling, the Player now also supports memory profiling. It reports object instantiations, object deletions and where objects were instantiated.
So far, I’ve talked quite a bit about the Player side of the Flex profiler story. Let’s turn to the profiler architecture. It is actually pretty simple. There are 4 pieces:
- The flash.sampler.* API support and the PreloadSwf support in the Player
- ProfilerAgent.swf as the PreloadSwf
- Java-based profiler client library
- Eclipse plugin + the graphical user interface
For performance profiling, the flash.sampler API returns sampling data as a stream of stack traces. So, it’s pretty easy to process. For memory profiling, the API returns object instantiation and deletion events and also stack traces indicating where objects were instantiated.
The PreloadSwf support is new in the latest Player. The idea is that, if you specify a local SWF in your mm.cfg, the Player will load/run the specified SWF in parallel to the target SWF. These two crucial Player features together provide the one-two punch we desperately needed against slow-running Flash movies.
Now anyone could write some AS3 codes to collect performance and memory data. For the Flex Builder profiling feature, we implemented a non-GUI-based AS3 program (ProfilerAgent.swf) that collects and sends performance/memory data to Flex Builder via socket connections.
On the client side, there are two pieces. The first piece is the Eclipse plugin and the graphical user interface. The “Flex Profiling” perspective and the associated views (a total of 11) are a major addition to Flex Builder 3. The user interface is aimed at:
- identifying performance bottlenecks
- exposing excessive object allocations
- finding loitering objects
The second piece is the profiler client library. Obviously, it’s for maintaining server socket connections; taking performance/memory data; processing them and archiving them. We need this library because we need a demarcation between the Eclipse code and the non-Eclipse code so that QA can use the Eclipse-free client library to write automated test cases for ProfilerAgent.swf.
If you want to know how to use the Flex Profiler, please check out the livedocs (http://livedocs.adobe.com/flex/3/html/help.html?content=profiler_3.html).
To Be Continued…
[…] 28, 2008 by Clement Wong If you haven’t read my previous blog about the Flex Profiler, I recommend you go take a […]
The Future of The Flex Profiler « Stop Coding!
April 28, 2008 at 6:10 pm
[…] to talk about, but this would be huge! It would be a frickin’ huge amount of work, but it is possible. And perhaps CoreData could lift a good amount off work of that […]
nesiumdotcom » Blog Archive » Pimping Trazzle
October 20, 2008 at 7:34 am
Hi,
I’ve just posted an article about getting the profiler to work, that mentions your post. If you get some lost souls trying to get it to work, it could be of use. Thanks for your own post which was of great help!
http://arielsommeria.com/blog/?p=48
ariel sommeria
December 22, 2008 at 4:58 am
I would like to run QA tests to profile my Flex application and am in desperate need of some documentation about the protocol between the ProfilerAgent.swf and the Java-based profiler client library – or even better the Java-based profiler client library API. Where do I find the client library jar within Flex Builder 3? Any chance to get some more information?
Thanks and Regards,
Peter
Peter
July 5, 2009 at 5:45 am
If I can tell you, I would. The protocol is proprietary… hence there is no documentation. I urged them to expose the Java API for the profiler client library so people can develop plugins for more profiling data visualization. I hope they’re going to do something in 4.0
Clement Wong
September 25, 2009 at 4:32 pm
[…] https://stopcoding.wordpress.com/2008/04/26/lets-talk-about-the-flex-profiler/ […]
MAX Presentation – Tackling Memory & Performance in Flash, Flex, and AIR | The World In A State of Flex
October 11, 2009 at 8:51 pm
Might want to take a look at this blog.
http://wceii.blogspot.com/2009/10/continuation-of-flex-memory-usage.html
II
December 1, 2009 at 10:24 am
[…] from the Flex SDK team, presents PreloadSwf as a piece of the “Flash profiling” puzzle in his about the Flex profiler post in 2008. If you want to know most of the secrets of mm.cfg, dive into Jean-Philippe […]
Philippe.me » AS3 – Hacking PreloadSwf for fun and profit
September 28, 2010 at 5:34 pm
[…] Hydro Series H80 High Performance Liquid CPU Cooler (CWCH80)J2EE Performance Profiling tools:Let’s Talk About The Flex Profiler if (top!=self) { window.location = […]
Performance Profiles: The Building Blocks of an Evidence-Based Talent Strategy | CallCenterBestPractices.com
September 23, 2011 at 11:17 pm
Now I know why the profiler works so well.
Yuri
January 13, 2012 at 8:41 pm