Alex, do you know what <DefineBitsLossless2 id='xxx' encoding='base64'> are? There are around 10k lines from this kind of definitions out of 11.5k lines. The traits you're talking about are placed before this definitions?
On 28 March 2014 17:00, Alex Harui <aha...@adobe.com> wrote: > 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" <joaopedromartinsfernan...@gmail.com> > 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 <aha...@adobe.com> 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 <joaopedromartinsfernan...@gmail.com> > >> Reply-To: "users@flex.apache.org" <users@flex.apache.org> > >> Date: Friday, March 28, 2014 8:13 AM > >> To: "users@flex.apache.org" <users@flex.apache.org> > >> 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 <aha...@adobe.com> 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" > >><joaopedromartinsfernan...@gmail.com> > >> 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 > > -- João Fernandes
