Hmm. Those are pretty substantial modules. I assume you've optimized out all the classes you can?
I haven't looked at Scout output too much so I don't have a sense of what that number looks like in other situations. But consider this: a 300K swf expands to about 600K, almost all of which is frame 2 ABC code. The player thrn has to do a for loop over all of the traits data and build up structures. You can use SWFDump to see roughly how much traits data there is. The first part of the SWFDump is the constant pools and traits. Once you see the actual code for your methods that is the end of the traits data. If you must load that much code while maintaining a smooth animation, you might need to distribute the code out on several frames, or break the big module into smaller ones. But it might be easier to mess with the user experience. Any time someone re-focuses or re-targets I think you can buy half a second. -Alex On 3/28/14 9:40 AM, "João Fernandes" <[email protected]> wrote: >Ok Alex, it seems I was profiling a debug version of the app and not the >release one. The sabe build using a release version is around 1/4 of the >debug one. So I still get around 200ms to 400ms per module (between 300k >to >800k in size).Is this more "acceptable" as overhead? I still find it too >much considering that apps can have something in between 12 to 20 fps and >clearly this times are way above the budget. > > >On 28 March 2014 16:27, Alex Harui <[email protected]> wrote: > >> Yes, the images say self time is 1.6 seconds. How big is the module? >> It might be interesting to see what the FB profiler shows. >> >> -Alex >> >> From: João Fernandes <[email protected]> >> Reply-To: "[email protected]" <[email protected]> >> Date: Friday, March 28, 2014 8:13 AM >> To: "[email protected]" <[email protected]> >> Subject: Re: Preparing ActionScript Bytecode >> >> >> I think it's the self time (single frame) as you can see here [1][2][3]. >> The percent time is above 90% of the total frame time. >> >> >> >> [1] >> >>https://www.dropbox.com/s/x7suurimsxqhixk/Captura%20de%20tela%202014-03-2 >>8% >> 2015.06.53.png >> < >> >>https://www.dropbox.com/s/x7suurimsxqhixk/Captura%20de%20tela%202014-03-2 >>8 >> %2015.06.53.png> >> [2] >> >>https://www.dropbox.com/s/x7suurimsxqhixk/Captura%20de%20tela%202014-03-2 >>8% >> 2015.06.53.png >> < >> >>https://www.dropbox.com/s/x7suurimsxqhixk/Captura%20de%20tela%202014-03-2 >>8 >> %2015.06.53.png> >> [3] >> >> >> >> >> On 28 March 2014 15:04, Alex Harui <[email protected]> wrote: >> >> Is that cumulative time or self time? What % of total time are you >>seeing? >> >> I thought that was simply the parsing of the module's ABC code. It >> shouldn't take long on its own and should be directly related to the >> amount of code in the module. >> >> -Alex >> >> On 3/28/14 7:42 AM, "João Fernandes" >><[email protected]> >> wrote: >> >> >I've noticed a lot of time is spent is this process when a module is >> >loaded >> >(movieClip.nextFrame > preparing ActionScript Bytecode) and I wonder if >> >there is any way to optimize and prevent so much overhead in this >>process. >> > >> >-- >> > >> >João Fernandes >> >> >> >> >> >> >> >> >> >> -- >> >> João Fernandes >> >> > > >-- > >João Fernandes
