Both Scout and the FB Profiler should be able to show you the top most expensive functions. If you post a screen shot we can see if there is anything unexpected in there. Usually it is just more LayoutManager methods and when you get down to specific component methods it is a low percentage, but you never know.
On 10/23/13 5:39 PM, "[email protected]" <[email protected]> wrote: >In Scout, the Summary panel shows: > >Total Frame Time = 1601 ms >ActionScript3 = 1443 ms >DisplayList Rendering = 25 ms >Other = 131 ms > >----- Original Message ----- > >From: "Maurice Amsellem" <[email protected]> >To: [email protected] >Sent: Wednesday, October 23, 2013 5:21:45 PM >Subject: RE: any techniques to spread drawing of screen over several >frames? > >Hi, >In Scout, you can the breakdown of rendering vs actionscript for that >particular 2sec frame. >What are the values ? > >Maurice > >-----Message d'origine----- >De : [email protected] [mailto:[email protected]] >Envoyé : jeudi 24 octobre 2013 02:12 >À : [email protected] >Objet : Re: any techniques to spread drawing of screen over several >frames? > >That's a good suggestion Mark. I tried turning various components >invisible, which didn't have any impact really. But it sounds like I >should have used excludeFrom or includeIn instead. I can try again. > >----- Original Message ----- > >From: "Mark Fuqua" <[email protected]> >To: [email protected] >Sent: Wednesday, October 23, 2013 4:57:17 PM >Subject: RE: any techniques to spread drawing of screen over several >frames? > >I am pretty clueless and don't want to imply anything different, but >could you just comment out a bunch of components, then some others, >narrowing it down...keep running the test until you see a spike? > >Mark > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Wednesday, October 23, 2013 7:27 PM >To: [email protected] >Subject: Re: any techniques to spread drawing of screen over several >frames? > >Suppose I take the trick below to divide the view up into two states, >such that half of the original first state's components are drawn in the >first state, then some time later, the other half of the components get >drawn. > >How could this second state be called after the first state is drawn? I >don't think there's a creationComplete available for spark states... not >sure what else I could use. > >Also, for this trick to work, would half of the components be set to >visible=false in the first state, and all the components be set to >visible=true for the second state? > >----- Original Message ----- > >From: "Alex Harui" <[email protected]> >To: [email protected] >Sent: Wednesday, October 23, 2013 3:25:28 PM >Subject: Re: any techniques to spread drawing of screen over several >frames? > >Also note that, sometimes, 23 is the right number. If you have several >HTTP requests coming in with data to fill combobox dataproviders with the >list of cities, categories, etc, you may end up getting invalidated for >each results event. > >-Alex > >On 10/23/13 3:21 PM, "[email protected]" <[email protected]> >wrote: > >>Thanks Alex, you've been very helpful. I can't say I know enough to fix >>it, but I can understand the complexity of the problem. >> >>----- Original Message ----- >> >>From: "Alex Harui" <[email protected]> >>To: [email protected] >>Sent: Wednesday, October 23, 2013 3:10:07 PM >>Subject: Re: any techniques to spread drawing of screen over several >>frames? >> >>In a very simple app, clicking on a button might generate one call to >>doPhasedInstantiation, and creating the new view should generate 1 to 3 >>more so that's a total of 4, not 23. An idle app does not generate >>calls to doPhasedInstantiation. Moving a mouse over rollOver targets >>can, though, so be careful with moving the mouse when taking snapshots. >> >>Sometimes a more complex view assigns data that came in asynchronously >>and that will generate another 3, bringing you to 7. >> >>So now, it is time to justify those other calls. You can try setting >>breakpoints in the debugger and see what is in the priority queues, you >>can monkey patch LayoutManager, uncomment all the trace statements and >>get sort of a dump of what happened, or you can keep analyzing the >>snapshot. >>I look for updateDisplayList call counts next. There should be one per >>visible component. Anything else is essentially wasteful. >> >>One customer was binding widths and heights to widths and heights of >>other things, which causes excess laying out. Another customer was >>using a third-party application framework and a third-party string >>resources library that did its work on creationComplete which also >>triggered excess layouts. >> >>HTH, >>-Alex >> >> >>On 10/23/13 2:52 PM, "[email protected]" <[email protected]> >>wrote: >> >>>Thanks Alex, >>> >>>It shows 23 calls to LayoutManager.doPhasedInstantiation. >>> >>>Note that I clicked "Reset...", then clicked the button that switches >>>the app to the new view state, then waited for the state to display >>>completely on the screen, then clicked "Capture...". I'm sure there >>>were many frames that occurred between clicking "Reset..." and >>>"Capture...", one of which was the long frame in question. Not sure >>>how to isolate the capture to that particular long frame in question >>>... should I worry about this? >>> >>>----- Original Message ----- >>> >>>From: "Alex Harui" <[email protected]> >>>To: [email protected] >>>Sent: Wednesday, October 23, 2013 2:37:50 PM >>>Subject: Re: any techniques to spread drawing of screen over several >>>frames? >>> >>>You want to do performance profiling instead of memory profiling in >>>the FB profiler. >>> >>>Can you control when the code you want to profile will run? Maybe by >>>clicking a button or something? >>> >>>When you launch the profiler, check both the memory and performance >>>boxes, then the app should start up. In the profiler perspective, >>>there should be two tabs in the upper right "Profile" and "Saved >>>Profile Data" and next to that are a bunch of icon buttons. One has >>>the tooltip "Reset Performance Data" and the other is "Capture >>>Performance Profile". Click the "Reset..." button then hit the button >>>in your app that will run the code, then go back to the profiler and >>>hit the "Capture..." button. That should put a performance snapshot in >>>the "Profile" tab that you can double-click to view, and that has call >>>counts. >>> >>>On 10/23/13 2:29 PM, "[email protected]" <[email protected]> >>>wrote: >>> >>>>Sure, How should I view the call count for >>>>LayoutManager.doPhasedInstantiation? >>>> >>>>Do I simply capture a Memory Snapshot before-and-after transitioning >>>>to the view in question, then highlight these two snapshots, then >>>>click on the Find Loitering Objects icon? At that point what am I >>>>looking for (I don't see a LayoutManager Class in the Loitering >>>>Objects panel like I did in the Live Object panel)? >>>> >>>> >>>>----- Original Message ----- >>>> >>>>From: "Alex Harui" <[email protected]> >>>>To: [email protected] >>>>Sent: Wednesday, October 23, 2013 2:17:06 PM >>>>Subject: Re: any techniques to spread drawing of screen over several >>>>frames? >>>> >>>>Well, those numbers mean that a lot of work is going on, but it is >>>>hard to say if it is excessive without call counts. Let's see what >>>>the FB profiler has to say. >>>> >>>>-Alex >>>> >>>>On 10/23/13 2:08 PM, "[email protected]" <[email protected]> >>>>wrote: >>>> >>>>>Thanks Alex, >>>>> >>>>>I searched, and I'm not using creationPolicy in the app. >>>>> >>>>>I'm using spark State, rather than a navigator view (such as spark >>>>>NavigatorContent). >>>>> >>>>>I do see in Scout that the LayoutManager.doPhasedInstantiation >>>>>(mx.managers) occupies 98% of the total time for the frame in >>>>>question. >>>>>If I analyze the memory allocations, I see (for the specific frame >>>>>in >>>>>question): >>>>> >>>>>LayoutManager.doPhasedInstantiation (mx.managers): Allocations = >>>>>63405 >>>>>(memory=19600 KB) >>>>> >>>>>which is broken down as: >>>>> >>>>>- LayoutManager.validateProperties (mx.managers): Allocations = >>>>>34210 >>>>>(memory=11327 KB) >>>>>- LayoutManager.validateDisplayList (mx.managers): Allocations = >>>>>25588 >>>>>(memory=7137 KB) >>>>>- LayoutManager.validateSize (mx.managers): Allocations = 3607 >>>>>(memory=1137 KB) >>>>> >>>>>I have no idea if this is good or bad, as something allocated may >>>>>have gotten deallocated via garbage collection (?). >>>>> >>>>>I've used FB profiler before, but I tend to got lost among all the >>>>>data and windows to the point where I don't know what's going on >>>>>anymore. >>>>>Is >>>>>there an easy way to extract the call count for >>>>>LayoutManager.doPhasedInstantiation for a specific frame (and how to >>>>>identify that frame in the first place)? >>>>> >>>>>I've started up the Profiler just now and it's exhibiting some odd >>>>>behavior. The timeline grows as expected, but even though my app is >>>>>running fine, the profiler shows no activity (the Memory Usage graph >>>>>is flatlined at 0 and the Live Objects table is empty). I tried on >>>>>FB 4.6 and 4.7, same result. It used to work fine on FB 4.6. Any >>>>>idea what it could be? The application path points to the correct >>>>>bin-debug/Main.html file... >>>>> >>>>>----- Original Message ----- >>>>> >>>>>From: "Alex Harui" <[email protected]> >>>>>To: [email protected] >>>>>Sent: Wednesday, October 23, 2013 12:20:11 PM >>>>>Subject: Re: any techniques to spread drawing of screen over several >>>>>frames? >>>>> >>>>>I still haven't used Scout. I have used the FB Profiler so I'm just >>>>>more used to it. Probably time for me to try Scout. Anyway, the >>>>>first thing I would check is the call counts. I heard you may not be >>>>>able to get that from Scout so you may need to use FB. >>>>> >>>>>Try to get the call count for LayoutManager.doPhasedInstantiation >>>>>for that frame It should be a small number like 3 or 4. If it is >>>>>higher, then there is extra invalidation going on that, if you can >>>>>eliminate it (and you can't always) could drastically affect the >>>>>execution time of that frame. >>>>> >>>>>A new navigator view should switch the LayoutManager to phased >>>>>instantiation mode and spread the validation across multiple frames >>>>>so mouse cursor doesn't stick. >>>>> >>>>>Also make sure you are not using creationPolicy="all" in any >>>>>navigators. >>>>>That is always a performance killer. >>>>> >>>>>Only instantiate components that are visible. Postpone instantiation >>>>>of components that aren't. >>>>> >>>>>You can use various tricks like changing states to incrementally add >>>>>more components to the screen. >>>>> >>>>>You can use modules to load whole sections of UI "later". >>>>> >>>>>-Alex >>>>> >>>>>On 10/23/13 12:03 PM, "[email protected]" >>>>><[email protected]> >>>>>wrote: >>>>> >>>>>>One of the views in my app takes a few seconds to appear on the >>>>>>screen. >>>>>>During this time the mouse icon appears frozen (recovering after >>>>>>the screen is fully drawn). >>>>>> >>>>>>Profiling with Scout, I can see the related frame, which, this one >>>>>>frame, takes a couple seconds to complete. I'm guessing this is due >>>>>>to a fairly complex view to layout and draw. >>>>>> >>>>>>When I implement a stopwatch timer throughout the ActionScript >>>>>>code, the times spent within the functions are negligible. So I'm >>>>>>guessing most of the time is spent behind-the-scenes somewhere >>>>>>drawing things. >>>>>> >>>>>>I tried using callLater() in various places, but this just led to >>>>>>problems since it changed the intended execution order of the code. >>>>>> >>>>>>Are there any techniques to force this drawing to occur over >>>>>>several frames so the mouse doesn't appear frozen to the user? >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > > > >
