Next the the performance snapshot button is this thing that is supposed to look like an eraser. The tooltip should say something like “clear performance data”. Normally, you would hit the clear button then open the popup then take your snapshot. If you need more pinpoint control, you can use the flash.sampler.* APIs to call clearSamples and stopSampling so you don’t get extraneous stuff in your report, but most of the time that stuff doesn’t show up in the top 30 so it doesn’t matter.
I’m not going to analyze the screenshot you posted. I will wait until you post one you feel contains the right data.
Thanks, Alex. I think now I am getting the correct snapshot and I don't have  methods anymore.I see that most of the top 30 methods are methods from our code while there are some Flex's too. Do I understand correctly that a total of cumulative time of all methods should be the total running time of a screen I am analyzing? Do you still recommend posting top 30?
Thanks for you help.
If you look at the top 30, some of them are called by things higher up, so you can’t add it all up and get the total run time. So for me, I never worry about the actual numbers I see in the time columns, I just trust that they are in the right order.
Whether there are  methods or not isn’t that important. All you are saying is that your code and flex code is dwarfing the player code.
Feel free to post the snapshot if you want.
This is for a popup?
OK, here’s what I see in the snapshot:
1) UIComponent.initialize() - This gets called once per UIComponent instance. This means that in the duration of this sample, 2236 UIComponents were created. That is way more than I would expect, even for a full screen popup with a DataGrid. Most of the time when I see this, folks are using creationPolicy=”all”. Yes, I know not using makes some code harder to write, but that’s the price you pay.
2) LayoutManager.doPhasedInstantiation() - This gets called 3 times in a well-behaved popup. Maybe 6 times if data is loaded later. The report says it was called 32 times, which indicates excessive invalidation. Binding component sizes and positions to other component’s sizes and position can sometimes cause this.
3) UIComponent.addChildAt() - This report says that some 1741 children were added to the display list. It could be due to creationPolicy problems, or else some other code is causing children to be added and removed. Maybe if you are swapping in skins late in the game you can get that to happen.
4) Responder.result – This report says that 143 network results returned during the sample. That’s an awful lot of data or at least requests. And if the result event causes the UI to re-do itself that will result in lots of UIComponents being created and added to the display list.
So, while code from your packages are in the top 6, the question is whether those methods get invoked by all of this network results activity or vice-versa.