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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >>
> >> >
> >>
> >
>
