How big are my Flex classes?

Joe Berkovitz has an entry here about a Java class in the free Flex 2 SDK that exposes how big each of your compiled ActionScript classes are in a given SWF. When an ActionScript class is compiled, it goes through a series of steps to become bytecode, a smaller size, more machine friendly format called “abc”. So, your 6k ValueObject could become 1k, not including the additional LZW “ZIP” compression that the Flash Player has built in for it.

For Flex Developers, this is valuable if you are trying to reduce the file size of your Flex app, usually in the case of a publicly accessible application. If 9 million people a day are accessing your SWF on 12 Akamai servers, it behooves you to make her as small as possible, even if money is no option. However, one of the biggest problems with modules, a feature in Flex 2.01 that allows you to separate parts of your application out into “dynamically loadable DLL’s”, is there really isn’t a straightforward way to understand what parts of your application could benefit from modules.

For example, as a GUI developer, I can pretty easily look at a design comp, and identify which parts would benefit from being loaded on the fly, and which are fine to just keep in the main SWF given the file size and performance requirements. If file size is important, later forms I can “load later” via a module so the larger PNG graphics don’t get included in the initial download. The user doesn’t need to see that form immediately, so I won’t make them download it immediately. The same goes for classes that aren’t seen. The code that makes up the form, for example, can only be download when the graphics that make it up are downloaded as well. Both of these can be packaged up in a module, and loaded on the fly later.

Regardless, that’s good foresight, but extremely subjective. I have no solid evidence of the classes size, including dependencies, just the PNG graphics size once I rip them out of the PSD /AI file. Furthermore, if the form has an initial transition, and it is choppy because the form has to load a lot of assets into memory when it downloads and then plays, the designer will give me hell. Thus, we are back to having very subjective decisions guide our choices of which classes / assets go into modules, and those who stay in the main SWF. Not a very good way to make software.

Another example is, “He’s over 2000 lines long and the user barely ever hits this complicated form until the very end of this wizard… let’s invest time making this part a module because we ‘guess’ it’ll help.”

Joe Berkovitz’s Apollo app should help change that. Using the Java class in tandem with a Flex Tree and WebKit HTML control, you can get a visual breakdown of how big each class AND package is in your code base. Joe wants to code some additional “smarts” into the code to proactively identify some key bloat areas that could be broken down into modules (if I read his entry correctly). Even if he doesn’t, just a Tree with file sizes like he shows on his blog is enough for me to make more informed architecture decisions.

Send Joe cookies so he finishes this app.