Written by Simon Bailey

• Please see the bottom of this entry for and update to the post *

Over xmas I have been working on some examples to upload to this blog with one particular example utilising Flex Runtime Shared Libraries (RSL’s) in an ANT script.

I am very keen on the concept of RSL’s on the surface (who couldn’t be) although I have held my reservations. RSL’s sound very attractive with most online resources referring to them as a sure fire way to reduce your core application SWF size and therefore rapidly speeding up the load time within the browser. I noticed a few gaps though including: statistics on the Flex RSL’s cached within the Flash Player (of various framework releases), encryption (answered here) and which version of RSL is currently cached in the Flash Player. I am still very pro RSL’s and utilise them in my modular applications, but further testing has proved that they are not necessarily always the best option.

During a xmas discussion with Cliff Hall RSL’s came into play and we discussed the benefits with Cliff pointing out some valid facts which I then decided to follow up (Matt Chotin was very helpful on clarifying my final thoughts) and jot down in a blog post.

The general consensus is that RSL’s are the core method to speed up the application load time. The methodology behind this is that the core application SWF size reduction is the key, achieved by transferring the libraries to cache thus saving a download of 500-700K. Instead of this primary focus on SWF size, well implemented modular organisation should take higher precedence but I want to stick with the RSL’s for now.

The fly in the ointment for RSL’s was that the Flex framework has to be loaded into the main application SWF, and for this to occur a HTTP call gets made. Taking a simple modular example, this means the load up routine for your SWF would be either:

RSL routine + Load main swf + Load flex-rsl.swf + Load Module A swf + Load Module B swf

Standard routine + Load main swf + Load Module A swf + Load Module B swf

The second point above was the potential performance hit and it is this HTTP call and loading of an extra swf that I think deserves testing further before you decide to deploy client applications using RSL’s. You have to load the Flex framework no matter what, whether you bake it into the main application SWF or load it into the main SWF from the players cache, but its up to you to decide whether it is better to have the overheads of a HTTP call and loading of the SWF but not have the 500-700K framework download or alternatively download the extra 500-700k within the main application SWF.

I have run some tests my end and to be honest they are simple and quick and are definately not conclusive, it depends on various factors and mine may not be the same as yours. Preceding each of the first two tests all browser cache was cleared and I have setup the Flex framework and RPC libraries to be cached in the Flash Player. I also use flash.utils.getTimer() for my timing, which as the docs describe:

Returns the number of milliseconds that have elapsed since Flash Player was initialised

.

SWF not utilising RSL - link: [caption id=”attachment_595” align=”aligncenter” width=”196” caption=”No-RSL SWF Load times”][/caption]

SWF utilising RSL (with RSL already cached in the Flash Player) - link: [caption id=”attachment_598” align=”aligncenter” width=”198” caption=”RSL cached SWF”][/caption]

And here are the results following the SWF cached in the browser:

SWF not utilising RSL - link: [caption id=”attachment_600” align=”aligncenter” width=”186” caption=”SWF not using RSL (cached in browser)”][/caption]

SWF utilising RSL (with RSL already cached in the Flash Player) - link: [caption id=”attachment_601” align=”aligncenter” width=”192” caption=”SWF cached in browser and framework cached in Flash Player”][/caption]

As I stated above this is a simple test using a simple app, but it does go to show that you should thoroughly test out all avenues and not simply rely on RSL’s if load times of your application is pertinent. I was actually surprised that the application that did not utilise RSL’s was so significantly faster but I am sure with a larger scale application these differences would not be quite so dramatic.

Example source files

NOTE

I have just attempted an average of 20 tests for each of my examples (emptying browser cache between each test) which are (a) not using RSL and not cached in the browser (b) utilising RSL and not cached in the browser. The results were:

(a) Average load time of 675.6 ms (b) Average load time of 532.3 ms

The gap is closing, but still not much in it and a general inconsistency in times as you would expect, I still recommend testing what suits you and your client.

UPDATE

Following appreciated feedback from Darrell Loverin @adobe I have learnt some new facts in regards to RSL’s. The points are pretty pertinent in my eyes and require thought when utilising RSL’s in your application. + Darrell has stated that there is only a single http request made for an RSL uncached in the Flash Player (so if you also set the rpc library as RSL then that will also be a http request). + I have checked the above point using Charles and this is indeed correct, obviously only if your client has Store common Flash components to reduce download times in the Global Storage Settings Panel and also the RSL needs to be signed. If not then the browser caches the RSL’s and every time the user clears their cache, another http request is made to retrieve the RSL’s (as I have detailed in my blog post above). + Darrell pointed out that there was an issue with my RSL loading i.e. flashlogs showed it could not be found??? I checked my server and it was indeed there although when I tried to hit the swz file it showed up as could not be found. I found this post related to mime type in IIS and checked with my servers host technical support and they changed the settings as per the link provided. This seems to have fixed the problem. This is a big point to be aware of, you need to check if your deployed application is rolling over to unsigned RSL’s, if it is then you need to investigate the root of the reason and potentially check with yours or your clients server settings! + (This I was aware of but have not yet pointed out) - Obviously with each new release of an SDK you need to upload the latest RSL’s to your server (if that is how your choosing on storing and retrieving them) as you build newer applications that utilise these SDK’s. Also note that if you have older applications that reference specific pre-dated RSL’s then I would presume they need to also be kept on the server.

I hope that helps clear things up and please post if you disagree with any of the points above and I will seek to research and correct them.