Couple of things: 1) Regarding size differences for a simple module with RSL or static linking, I suspect the difference is that the static version doesn't have RSL management code injected into it. But in a more complex module that uses framework classes not used by the main app, the module must contain those framework classes when statically linked unless those classes are in a shared code module and also externally linked. I'm encouraging you to switch to static-linking not because the modules will be smaller (although with enough work you can make them smaller), but because the probability your customer will have to download the RSLs is increasing every day, and the total download time will be greater if you are using RSLs than if you static link.
2) Regarding your question about optimization of embeds, there are two factors involved. A) The module subsystem was meant to allow for modules to be unloaded. B) The compiler is not going to take the time to do flow analysis to determine when classes will be verified, so the entire class dependency tree referenced by the main app must be linked into the main app by default, unless you tell the compiler otherwise. So, by referencing the module class in the main app, you are not only adding it and its dependencies to the class dependency tree, but putting it in the main applicationdomain, so those classes cannot be unloaded. You can force the external linking of some of those classes/assets only if you know the verifier isn't going to throw an exception first. You may want to manually control the contents of the link-report that is used to optimize the module. Flash Builder doesn't know how to do this, so you'll have to use Ant and store the desired link-report somewhere or auto-generate it some how. But basically, there are enough options in the compiler to control which classes go in which SWF. But Flash Builder cannot do it for you automatically. And by choosing Apache Flex, you can make changes to the SDK that may be needed to better optimize your statically linked SWFs. And I would still recommend deeper analysis (if you have time) of the 600K you say is needed to generate the first screen. That still sounds like too much to me. -Alex On 12/4/13 8:20 AM, "David Coleman" <david_coleman_...@hotmail.com> wrote: > > > >First I made a simple application which you can see at: >https://github.com/davidcoleman007/AppWithOptimizedModules > >First, I tested WITHOUT referencing the module, just compiling with an >application and a module, but not actually referencing the module in the >application. I ran a grid of the main app and one of the modules, using >both static link/RSLs and optimized/normal module compilation. here are >the VERY interesting results (with debug compilation): > >(lobby == main app) >//---------------------------------- >//---------- with RSLs ------------- >// optimized >// inbox 378,681 bytes >// lobby 1,259,400 bytes >// normal >// inbox 390,652 bytes >// lobby 1,259,402 bytes >//---------------------------------- >//--------- static link ------------ >// optimized >// inbox 374,383 bytes >// lobby 2,745,913 bytes >// normal >// inbox 1,136,169 bytes >// lobby 2,746,063 bytes > >Optimized compilation of a module created a SMALLER main file and SMALLER >module file with both RSLs and static linking - not a great surprise, >since we all know that in theory optimization should do just that. > >However what REALLY surprised me and I suspect will surprise others, is >this: using static linkage, my optimized module was SMALLER than with >RSLs. > >So on the surface it really appears that Alex is right. Static is the >way to go. > >BUT!!! > >then i made a reference to the module in the main application, as you can >see in the git repo. > > import mx.events.FlexEvent; > protected var module:AnOptimizedModule; > protected function >onCreationComplete(event:FlexEvent):void { > }I did nothing with the module, i just referenced >it: > >here are the results: >//---------------------------------- >//---------- with RSLs ------------- >// optimized >// module : 73,116 bytes >// app : 7,411,954 bytes >// normal >// module : 7,407,431 bytes >// app : 7,411,955 bytes >//---------------------------------- >//--------- static link ------------ >// optimized >// module : 67,875 bytes >// app : 7,906,020 bytes >// normal >// module : 7,825,665 bytes >// app : 7,906,020 bytes > >as you can see, the compiler is clearly smart enough to move the big >embedded image OUT of the module and include it in the main app, but it >is not capable of the reverse which is to exclude it from the main app, >depending on its presence in the module. > >I know that this can be worked around with Interfaces, and tbh, that's >what i've done. but it's a workaround. the compiler should be smart >enough to leave [embed]'s in the module and not include them in the main >app. It's smart enough to move them OUT when you optimize the module. >Why can't it leave them IN instead, which would be the more logical >behavior? After all that is why a developer would most likely create a >module in the first place. And since a module will never be instantiated >w/o loading the corresponding SWF file, what point could there possibly >be for including the binary part of the class definition in the main app >when it references it? If it were a STATIC member of the module class >then i would understand it. but it is a public instance property... >Something here smells fishy to me. > >At the end of the day I'm still convinced that the compiler should behave >differently, but I see that Alex is quite right about static linking. >This is very encouraging!!! Hopefully sometime next year we can add a >facebook game to the list of applications that use Apache Flex! (don't >expect it soon, I'm up to my nose in a bazillion things, but this is >definitely on my "really-cool-thing-i-wanna-do" list). :) > > >> From: aha...@adobe.com >> To: dev@flex.apache.org >> Date: Tue, 3 Dec 2013 20:12:32 -0800 >> Subject: Re: SharedLibrary not works with SDK 4.11 >> >> Wow. I don't think it is supposed to do that. Please create a simple >> test case and create a JIRA issue. >> >> -Alex >> >> On 12/3/13 5:53 PM, "David Coleman" <david_coleman_...@hotmail.com> >>wrote: >> >> >For instance i have an app in flash builder with a boat load of modules >> > >> >I set one of these modules to be optimized for MyApp.mxml >> > >> >the embedded images in MyOptimizedModule end up in MyApp.mxml. >> > >> >The good thing is that MyApp and MyOptimizedModule can now be >>statically >> >linked w/o doubling its size. the bad thing is that now I have >>defeated >> >the purpose of putting my assets in the module. >> > >> >can I optimize a module for MyApp without all of its embedded assets >> >ending up in the optimization target? >> > >> >It is my understanding that optimizing a module for a specific >> >application ends up removing all embedded assets from the module and >> >storing them in the application. >> > >> >If you want i can reproduce this in a few example projects and post it >>up >> >on my git. >> > >> >> From: aha...@adobe.com >> >> To: dev@flex.apache.org >> >> Date: Tue, 3 Dec 2013 17:19:06 -0800 >> >> Subject: Re: SharedLibrary not works with SDK 4.11 >> >> >> >> I don't understand the part about embedded assets. Can you provide >>more >> >> details? The -externs option should let you keep any class out of >>any >> >>SWF. >> >> >> >> You can create a shared code module or pack other classes needed by >> >> modules onto extra frames of the main SWF. >> >> >> >> -Alex >> >> >> >> On 12/3/13 4:05 PM, "David Coleman" <david_coleman_...@hotmail.com> >> >>wrote: >> >> >> >> >I do agree with your numbers, (how could I not - they are spot on). >> >>The >> >> >primary issue is that WE host the rsl or the static link difference. >> >>and >> >> >the static link difference affects the size of our modules too. So >> >>it's >> >> >100% more for modules, and since we have 7.8 MB of modules (18 >> >>different >> >> >popups each with animations/hd graphics etc), then we are talking >>about >> >> >static linking costing a lot more. >> >> > >> >> >If i can customize an RSL to service all 18 modules and the main app >> >>and >> >> >only have to distribute one file, that is even better for a new user >> >>than >> >> >the Adobe RSL's... ok we have to pay for the CDN costs... but it's >>less >> >> >than an extra 7.8 MB of static links for all our modules. >> >> > >> >> >Harbs pointed out the exact reason RSL is so critical to our use >>case. >> >> >Modules are doubled. >> >> > >> >> >Now, if the modules could only statically link what is lacking in >>the >> >> >static links of the main application, with out optimizing them and >> >> >pushing all the embedded assets to the main application... kinda >>like a >> >> >"half-optimized" module, then static link could really work for us. >> >>but >> >> >as long as an optimized module will push all the assets into the >>main >> >> >app, i can't optimize them to share the static links. so they need >> >>their >> >> >own static links... >> >> > >> >> >Maybe this is something that can work! >> >> > >> >> >how can i optimize a module to share the static links of the main >>app >> >> >without pushing all the embedded assets in the module to the main >>app? >> >> >does mxmlc include a metatag to exclude a class (embedded asset) >>from >> >> >module optimization? so it would stay in the module while i >>optimize >> >>it >> >> >for the main app, and then only have to statically link the few bits >> >>and >> >> >pieces that are lacking in each. >> >> > >> >> >> From: aha...@adobe.com >> >> >> To: dev@flex.apache.org >> >> >> Date: Tue, 3 Dec 2013 15:51:44 -0800 >> >> >> Subject: Re: SharedLibrary not works with SDK 4.11 >> >> >> >> >> >> OK, so let me make sure I understand: >> >> >> >> >> >> For first time users, they have to download 3MB of Assets and the >> >>600K >> >> >>SWF >> >> >> and hopefully not the 1.4MB's of framework RSLs. >> >> >> For returning users, 3MB Assets and 600K SWF is hopefully in the >> >>browser >> >> >> cache. >> >> >> >> >> >> If you switch to Apache Flex: >> >> >> First-time users will have to download either >> >> >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. >> >> >> 2) 3MB of Assets and 1.2MB of SWF if you statically link. >> >> >> >> >> >> So, Apache Flex statically linked is another 600K and represents >>an >> >> >> additional 12% in download time. >> >> >> >> >> >> I don't know what the RSL penetration is of Flex 4.5.1, but every >>day >> >> >> folks are buying new computers and there are fewer and fewer Flex >> >>4.5.1 >> >> >> apps out there in the world so the probability your first-time >> >>customers >> >> >> will have those RSLs is diminishing. Over time, more and more of >> >>your >> >> >> customers will be downloading the 1.4MB of framework RSLs as well, >> >>and >> >> >>the >> >> >> statically linked solution will be the smaller download. >> >> >> >> >> >> Have you used ItDepends or a similar link-report analyzer to see >>how >> >> >>much >> >> >> of that 600K is Greensock, Tweener and other stuff? >> >> >> >> >> >> -Alex >> >> >> >> >> >> On 12/3/13 3:11 PM, "David Coleman" >><david_coleman_...@hotmail.com> >> >> >>wrote: >> >> >> >> >> >> >Upon re-reading this I realize that I didn't understand your >> >>question. >> >> >> > >> >> >> >What it will save us is that in the majority of instances, we >>will >> >> >> >benefit from the cached RSL. >> >> >> > >> >> >> >And we will be able to still push smaller files so that NEW >>users do >> >> >>not >> >> >> >see a jump in the time that it takes to open the app. >> >> >> > >> >> >> >Competition is high in this genre of games, and being the >>fastest to >> >> >>load >> >> >> >is important. We won "Best social Casino Product of 2013" this >> >>year. >> >> >> >Maybe if we were not the fastest to load we might have still won. >> >> >>Maybe >> >> >> >not. But we are. And I would hazard the guess that it played a >> >>role. >> >> >> >Many ppl already HAVE the RSL's cached on their machines. I >>have to >> >> >> >offset that benefit by minimizing as much as possible the hit >>that >> >>any >> >> >> >Apache based solution would incur. >> >> >> > >> >> >> >As with any social game the first impression is the most >>important >> >>one. >> >> >> >Especially with those who are disposed to spend real money. I >>know >> >> >>that >> >> >> >TECHNICALLY there are many reasons to just link it statically and >> >> >>forget >> >> >> >about it. But from a business perspective, every shred of speed >> >>that >> >> >>we >> >> >> >can statistically extract from the app is worth it. >> >> >> > >> >> >> >I can't justify moving all the framework RSL's to our CDN and >> >>storing >> >> >> >them in browser only cache instead of perpetual flash player >> >>storage. >> >> >> >That's why I asked about local storage hacks. I CAN justify >> >>putting a >> >> >> >SINGLE file on our CDN, if it means greater stability (ie: new >>SDK) >> >>and >> >> >> >downloading a smaller amount of bytes than the 4.5.1 RSL's. a >>few >> >> >>bytes >> >> >> >are big money when you are distributing them to a million ppl. >> >> >> > >> >> >> >Unfortunately, that's the reality of the business side of a >>social >> >> >>app. :( >> >> >> > >> >> >> > >> >> >> >> From: david_coleman_...@hotmail.com >> >> >> >> To: dev@flex.apache.org >> >> >> >> Subject: RE: SharedLibrary not works with SDK 4.11 >> >> >> >> Date: Tue, 3 Dec 2013 19:56:13 -0300 >> >> >> >> >> >> >> >> It saves us a great deal of time and resources when we have to >> >> >>release >> >> >> >>new art. >> >> >> >> >> >> >> >> We can break cache on the art asset module and not have to run >>a >> >>full >> >> >> >>QA regression on the main app. This gives us the flexibility >>as a >> >> >> >>company to deliver constantly changing content to our users w/o >> >> >>forcing >> >> >> >>them to download every file again, or dedicating our time and >> >> >>resources >> >> >> >>to QA of the application when we only want to change a single >> >>image in >> >> >> >>the game list. >> >> >> >> >> >> >> >> It is a logistical and political need as much as it is a >>technical >> >> >> >>decision to approach it this way. >> >> >> >> >> >> >> >> > From: aha...@adobe.com >> >> >> >> > To: dev@flex.apache.org >> >> >> >> > Date: Tue, 3 Dec 2013 14:43:33 -0800 >> >> >> >> > Subject: Re: SharedLibrary not works with SDK 4.11 >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > On 12/3/13 2:38 PM, "David Coleman" >> >><david_coleman_...@hotmail.com> >> >> >> >>wrote: >> >> >> >> > >> >> >> >> > >Actually Alex, what is the biggest culprit in our file is >> >> >>Greensock, >> >> >> >>and >> >> >> >> > >after that, a whole mess of engine logic needed to handle >>the >> >> >> >>interface >> >> >> >> > >with the games. Also some of our legacy animations use >> >>Tweener, >> >> >>so >> >> >> >>for >> >> >> >> > >now I'm cursed with having to include BOTH libs in the main >> >>app. >> >> >> >> > > >> >> >> >> > >I also think that 500K is too much and like I said, each >> >>version I >> >> >> >> > >whittle it down a little more. >> >> >> >> > > >> >> >> >> > >I've often thought of loading the engine container as a >>module >> >>to >> >> >> >>remove >> >> >> >> > >another 100K or so from the main app. >> >> >> >> > > >> >> >> >> > >How would i create a custom RSL? Can I automate it via ant >>to >> >> >> >>generate >> >> >> >> > >it via the link-reports? I'd like to keep one RSL for ALL >> >>files, >> >> >> >>app, >> >> >> >> > >and modules to increase cache hits, and not hit a different >> >>file >> >> >>each >> >> >> >> > >time. >> >> >> >> > > >> >> >> >> > >I'm really curious to experiment with this. It's ok if the >> >> >>browser >> >> >> >>cache >> >> >> >> > >expires, that's beyond my control, but 99% of the time it >>will >> >>be >> >> >>a >> >> >> >> > >benefit - I'm ok with those numbers. >> >> >> >> > I asked this in the other reply, but how will that save you >> >>over a >> >> >> >>single >> >> >> >> > monolithic SWF? If you're not in the cache, then instead of >> >> >>loading >> >> >> >>two >> >> >> >> > things, one of which may contain classes you don't need until >> >> >>later, >> >> >> >>you >> >> >> >> > only load what you need when you need it. >> >> >> >> > >> >> >> >> > -Alex >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> > >
