subject:"RE\: SharedLibrary not works with SDK 4.11"

RE: SharedLibrary not works with SDK 4.11

2013-12-04 Thread David Coleman




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

Re: SharedLibrary not works with SDK 4.11

2013-12-04 Thread Alex Harui

 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

RE: SharedLibrary not works with SDK 4.11

2013-12-03 Thread David Coleman

http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarkscount=18fb_bmpos=3_18

the main file (for the upcoming version) is 566k, currently it is
slightly over 600K, the assets are ~3 mb and i have implemented most
popups as external modules, to ensure that they load from cdn only one
time per session.

The main application is a spark application. I use only simple objects,
Group, List etc... nothing uber fancy. Most of the heavy lifting is
done with AS3 for speed.

We have a very large number of users. I can't statically link the libs
because ppl expect the blinding fast load that I have achieved. 566K
loads in the blink of an eye on even mediocre systems/connections.

Personally I would prefer to statically link the framework because RSL's
are yet another hit the browser has to make, but we need the users to
get into the game and play as fast as possible. I have maintained the
fastest load in our category on facebook for
nearly a year now. :) I intend/need to keep it that way.

so your short answer is a very big, yet very, very SMALL and optimized
facebook app which is exactly why i have to use them :)

Any way around this limitation would open the door for me to promote and
fast-track the adoption of Apache Flex. I need small and I need fast.
The rest is academic. Once I have the tools, I'll make it happen, and
we will migrate to Apache Flex. Our target
Flash Player version is 10.3 for maximum penetration.

If there is any glimmer of hope to accomplish this... tell me, and let me know
how I can help.

From: aha...@adobe.com
To: dev@flex.apache.org
Date: Mon, 2 Dec 2013 11:22:26 -0800
Subject: Re: SharedLibrary not works with SDK 4.11

On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote:

Having not tried this solution myself, this is pure speculation... but
couldn't local storage store this? set domain to be * and retrieve it
from the public svn repo. if not present the RSL manager can load it up
and in this way we can sign it with our own Cert and validate that cert
independent of Adobe? Would this be workable?
I think you'd hit local storage limits.

RSL's are the only reason that I hesitate to migrate our Facebook app to
apache. it will kill our CDN.

Just curious: Have you actually measured the difference without RSLs? How
big a Facebook app is this?

-Alex

RE: SharedLibrary not works with SDK 4.11

2013-12-03 Thread David Coleman

that's 566k of code... the code is mostly the networking layer, and facebook 
interface controllers.

The 3 mb of assets load with the preloader and are broken into 2 modules so we 
can push art changes w/o pushing a whole new client.

The preloader is 33% of the main loading screen - what happens is you don't see
 the transition between preloader and application because I designed it 
that way, so it looks like a single process.  Basically I am already late 
loading the assets, but it is a requirement that the app be ready for 
interaction the moment the startup is done.

unfortunately, most of the assets are required.  for instance at least 1.5 to 2 
mb is consumed by the game icons which the user must see instantly, and the 
game order is dynamic so we can't separate them into multiple pages to lower 
the load.  Some minor optimizations can be made, and believe me, every few 
weeks I'm shaving a few K here or there.  But not enough to add hundreds of K 
in statically linked libs.

when i build (in debug) with static linking the size is 2,749,998  bytes vs 
1,262,589  bytes

in release there is a similar proportion:
1,225,769  bytes vs 609,402  bytes.  (with Ant builds these numbers are 
slightly smaller, which is where i get the 566K for our upcoming release).

basically the main file contains all the networking etc...  this is because the 
game must be instant-on users often claim gifts and enter the game in a flow 
which leads them directly to a popup or a slot, which means that the moment 
load is done, the app must be in gear ready to go.

is it possible to combine the framework rsls into a single file, and load it 
instead of the standard framework rsl's? So instead of loading 5 different 
rsls, I load a single optimized file that has only the classes needed for the 
app and its modules?

The standard rsls come to 1.41MB and the difference in release is 0.58 MB... 
obviously I'm not using the majority of the flex code base... can I strip this 
down somehow?

 From: aha...@adobe.com
 To: dev@flex.apache.org
 Date: Tue, 3 Dec 2013 10:20:07 -0800
 Subject: Re: SharedLibrary not works with SDK 4.11
 
 Hi David,
 
 So you are saying that there is 566K in non-Flex code and assets to
 generate the first screen (after the preloader)?  How much of that is
 assets and how much is code?  And what Flex classes are used in that first
 screen?  Usually, folks take a second after seeing the first screen before
 they act on it, and you can often do a bunch of downloading and
 initializing in that time.  If you move everything not required for the
 first screen to a late-loaded module, you might find that the total
 framework load goes down and static linking becomes possible.  That
 wouldn't be true for some app that has a DataGrid on the first screen, but
 I don't think I'm seeing heavyweight components on your first screen.
 
 -Alex
 
 On 12/3/13 6:41 AM, David Coleman david_coleman_...@hotmail.com wrote:
 
 http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarks
 count=18fb_bmpos=3_18
 
 
 
 
 
 the main file (for the upcoming version) is 566k, currently it is
 slightly over 600K, the assets are ~3 mb and i have implemented most
 popups as external modules, to ensure that they load from cdn only one
 time per session.
 
 
 
 
 
 The main application is a spark application.  I use only simple objects,
  Group, List etc...  nothing uber fancy.  Most of the heavy lifting is
 done with AS3 for speed.
 
 
 
 
 
 We have a very large number of users.  I can't statically link the libs
 because ppl expect the blinding fast load that I have achieved.  566K
 loads in the blink of an eye on even mediocre systems/connections.
 
 
 
 
 
 Personally I would prefer to statically link the framework because RSL's
  are yet another hit the browser has to make, but we need the users to
 get into the game and play as fast as possible.  I have maintained the
 fastest load in our category on facebook for
 nearly a year now.  :)  I intend/need to keep it that way.
 
 
 
 
 
 so your short answer is a very big, yet very, very SMALL and optimized
 facebook app  which is exactly why i have to use them :)
 
 
 
 
 
 Any way around this limitation would open the door for me to promote and
  fast-track the adoption of Apache Flex.  I need small and I need fast.
  The rest is academic.  Once I have the tools, I'll make it happen, and
 we will migrate to Apache Flex.  Our target
 Flash Player version is 10.3 for maximum penetration.
 
 
 
 
 
 If there is any glimmer of hope to accomplish this...  tell me, and let
 me know how I can help.
 
  From: aha...@adobe.com
  To: dev@flex.apache.org
  Date: Mon, 2 Dec 2013 11:22:26 -0800
  Subject: Re: SharedLibrary not works with SDK 4.11
  
  
  
  On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com
 wrote:
  
  Having not tried this solution myself, this is pure speculation... but
  couldn't local storage store this?  set domain to be * and retrieve
 it
  from

Re: SharedLibrary not works with SDK 4.11

2013-12-03 Thread Harbs

My educated guess on the size of such an app without using RSLs (depending on
exactly which classes you're using) is about double your current size. That's
still manageable. You can still use modules as you do today. Of course an issue
is going to be all the modules. Every module gets bigger without using RSLs.

Have you tried compiling without RSLs to see the actual difference in size?

Harbs

On Dec 3, 2013, at 4:41 PM, David Coleman wrote:

http://apps.facebook.com/houseoffun/?fb_source=bookmark_appsref=bookmarkscount=18fb_bmpos=3_18

The main application is a spark application. I use only simple objects,
Group, List etc... nothing uber fancy. Most of the heavy lifting is
done with AS3 for speed.

so your short answer is a very big, yet very, very SMALL and optimized
facebook app which is exactly why i have to use them :)

If there is any glimmer of hope to accomplish this... tell me, and let me
know how I can help.

From: aha...@adobe.com
To: dev@flex.apache.org
Date: Mon, 2 Dec 2013 11:22:26 -0800
Subject: Re: SharedLibrary not works with SDK 4.11

On 12/2/13 10:13 AM, David Coleman david_coleman_...@hotmail.com wrote:

RSL's are the only reason that I hesitate to migrate our Facebook app to
apache. it will kill our CDN.

Just curious: Have you actually measured the difference without RSLs? How
big a Facebook app is this?

-Alex

RE: SharedLibrary not works with SDK 4.11

2013-12-03 Thread David Coleman

You are right. using static framework linkage balloons the modules beyond
usefulness, easily double as you say, and sometimes more.

Ideally, there would be a way for me to build a special optimized single file
RSL, and use a third party software such as Kindi SecureSWF and sign it with my
own certificate, and then include in that RSL all the core classes needed for
everything, app, modules, etc...

certainly the overhead for a 3rd party certificate would be minimal compared to
the cost of linking the framework statically. And it would be nice to trim
down the framework to the bare essentials.

If i could hack the RSLs in this way then I could propose Apache Flex as being
more secure and lower weight than a 4.5.1 sdk solution. Sure I would need to
religiously maintain the contents of the FlexCore.swf RSL, but that's no big
deal. perhaps i could even write some nifty tool that uses ant that scans all
the unique classes used in the various link-report.xml's from the app and
modules and then auto package this RSL at build time...

I'm fully aware that this would be challenging... but I'm just trying to think
of a way to be able to take our app into the future using Apache Flex. I don't
want to be locked into 4.5.1 for the next 6 or more years of our application's
projected life. That's the lazy way out.

Subject: Re: SharedLibrary not works with SDK 4.11
From: harbs.li...@gmail.com
Date: Tue, 3 Dec 2013 22:12:00 +0200
To: dev@flex.apache.org

My educated guess on the size of such an app without using RSLs (depending on
exactly which classes you're using) is about double your current size. That's
still manageable. You can still use modules as you do today. Of course an
issue is going to be all the modules. Every module gets bigger without using
RSLs.