Optimizing Compile Times in Flex Builder – Gems from MAX

The background: we’re working on a huge application with .Net on the back end, WebOrb in the middle, and Flex front end. We are also using Cairngorm, which actually I’ve used on EVERY flex project since I first started developement using the Flex 2 Alpha release, but that’s pretty irrelevant to this post beyond the fact that it was cool to actually meet and discuss with Steven Webster. There’s also quite a bit of animation and cool fx – i.e. Flash/Flex integration. There are a few things that are different on this project than any of my previous flex projects:

• first time using WebOrb (we had some issues getting certain classes to come through properly over the WebOrb wire…when we put in a tech support request none-other than the CEO of WebOrb responded…)
• first time using .Net back end
• first time the dev server environment wasn’t on the developers’ local machines – we code locally but when FB builds the equivalent of the bin directory is on a remote machine, where WebOrb and .Net are also running. Each developer has his own dev machine setup like this. The reason for doing this was so that .Net developers could push out updates to their code to all dev machines easily, but it also caused build/compile issues on the flex development side
• first time using FileSync plugin for Eclipse – this was mandatory to overcome the initial brick wall caused by the previous point; without FileSync flex builder refused to build out to a remote location
• We’re developing using Flex 2.01 – we were specifically told not to use Flex 3 – because they didnt’ want to develop using ‘Beta-ware’

So that’s the background – while at MAX I got to interact directly with various folks from Adobe, like Steven Webster who I mentioned above, the entire Adobe Consulting group, Matt Chotin, and the Flex Builder QA team. Below are some of the gems I gleamed from them:

—

“Day 1 @ MAX”

I spent over an hour tonight with Steven Webster and the entire Adobe Consulting team having a very candid discussion. I also spoke with the CEO of WebOrb who had emailed back and forth a bit with us back when we were struggling with the .Net to Flex class issue.

I mentioned that we were having very long build times. First of all, they said to speak to Matt Chotin, who I also spent time with today but prior to speaking to Adobe Consulting team. Apparently Matt is heavily looking into compile time issues in Flex.

Secondly, AC mentioned that there is a known issue using embedded fonts, which I know we are using in our app. Apparently using embedded fonts increases build times quite a bit. They are looking into resolving this.

Tomorrow I will try to discuss with Matt to see what other ideas he might have.

Also, after several sessions with the flex team and talks by the flex team members, it has become apparent that Flex 3 is offering MAJOR performance improvements. Also, and invaluable feature in Flex 3 is the new profiler – which allows you to see exactly what classes are taking up CPU resources and to what extent, etc. Also a pet peeve I’ve had with Flex all along has been replaced by another awesome feature – code refactoring – now if you change a function name, it will refactor all your code for you – no more find/replace to do it manually. It’s all very, very cool…

—

“Day 3 @ MAX”

OK, Matt Chotin told me to speak with the FlexBuilder QA guys, which I did. They had several bits of advice, but the biggest one was -

switch to FlexBuilder 3. After the sessions I attended, I came to realize a few things more about FB3. Most pertinent to us – it ships with multiple SDKs. So you can open and edit you FB2 project and KEEP it a FB2 project – just as if you were working in FlexBuilder 2.01 – but you get added benefits like the profiler and huge performance increases during development.

Also they strongly suggested keeping FB building locally and having the swf run on the local machine. They said to use a trust file on each dev server (I’m assuming they mean a cross domain policy file) in order to let the swf communicate from the developers local machine with the server on the dev machine.

They mentioned the same thing Adobe Consulting mentioned earlier about embedded fonts increasing build times. But they said, if you have a number of fonts and graphic assets that aren’t changing constantly, then we should stuff those assets into a swc file. That way they won’t keep getting recompiled every time we do a build.

They also said to move parts of the application that the user wouldn’t necessarily always use, into modules. This has multiple benefits:

• the application will load much faster, as its not trying to load the entire app at one time
• the application will start faster
• the application will download faster
• the application won’t have to re-compile the modules, which again will save build time during development

Again, they kept emphasizing to use Flex 3, because they have really put a lot into performance enhancements.

One of the Adobe guys gave a talk on using the profiler, the profiler itself is documented but the walk-through was helpful. BTW Adobe Connect is getting replaced by a much more powerful app built in Flex. With the profiler you can pinpoint both memory and performance issues.

Another thing they said with relation to fonts that would increase performance, was that if the fonts we’re using aren’t really small then we should turn off FlashType (FlashType is deprecated and is now called AntiAlias, but since we would likely be using the Flex 2.01 SDK rather than Flex 3 SDK, we would use “FlashType”).

Finally, Daniel Rinehart from Allurent gave a talk describing how they work in groups of similar size to ours at their company (he also gave another talk on Continuous Integration in Flex the day before that). There were a couple of critical differences in the way they organize themselves and our situation, which seems to give them much better development and testing time frames. Like us, they have multiple developers on large teams working on different parts of a large application. However, in our case each developer creates a demo application file to test his or her own task. They have a different approach, though. They employ unit testing to verify that each developer’s sub-piece of the application works appropriately, and continuous integration to ensure that one developer’s changes don’t break something somewhere else int the application. And then here’s the stickler – the part that ensures their build times are not huge. They employ the [source] attribute in the application to reference relative paths…so that when a developer builds his flex builder isn’t pulling down the entire application to build, just his parts. Honestly the whole concept is a bit abstract for me and hard to follow, but I plan to contact him later to see if I can get some more details. I did take pictures though so here are some shots of his screen, maybe it will make more sense to you, the reader.

I also typed up notes during the Flex Boot Camp on Wednesday, which includes the notes from Daniel’s talk…I may share those later, but for now, here is the excerpt from Allurent (their Antrolpologie AIR app, developed in Flex, was shown off during the Keynote). Sorry, these notes are in their original form – i.e. quick notes taken during the session, not exactly verbose or even complete sentences. I will also be uploading pictures later which include the slides, etc. from the boot camp and all the other sessions I attended at MAX.

Allurent Notes:

—

Allurent (Anthropologie application)

Flex Development in Teams
20 Developers on number of projects…

-make heavy use of source control
–really like SVN – great plugin for eclipse, do diffs within eclipse
-peer reviews…adopt some Agile techniques without going pure XP
-have a team member review code before check-in

-integrate everything into a bug system – they use Bugzilla, JIRA is another great choice
-code organization – break project up into chunks
-use Wikis to share information
–design ideas, problems that they don’t want to fix right now, but let rest of team know
-do a lot with Unit Testing – great way to make sure that changes that one developer makes to one part of the system, don’t unintentionally break another part

-flex builder use perspective: check in all of .project and .settings files
–make use of linked resources settings
–can make __ links

Questions from me:
-why not pure agile?
-do they have big projects w/many demo files for the ‘pieces’ of the system – does it affect compile times of FB?
-no – they use unit testing. use SOURCE paths so don’t have to – compiles much faster, and can test parts of application independent of each other

[source path] motor-flex2

-which eclipse plugins do they find useful during flex development?

–subclipse plug-in

-a flex project is flex only, a java project is java only – mixing can get buggy

props – flex project nature – add flex project nature – allow you to build both flex and java pieces in same project
—

No-one else I spoke to is using the FileSync plugin for flex development…but also no-one is building their flex apps non locally.

So anyway, I hope some of the tips above prove useful to other flex development teams out there…