« Hello world | Main | Updates and Carrot Cake »

Speeding Up Mxmlc

Since this page is still very popular, I want to make clear that the change described below is for Flex 1.5 and does not work in Flex 2. The Java class for mxmlc in Flex 2 is "flex2.tools.Compiler", and Flex 2 has something like FastMxmlc built-in with the "incremental" compiler parameter.

A few weeks ago I posted on flexcoders my thoughts on how to speed up compilations from the command-line. At the end of the post there was one unanswered question in my mind- why didn't class caching work from the command-line? Class caching, aka SWO caching, is a way to speed up compilations by storing information on classes between compiles. This should work by default, but for a simple reason this was only working when compiling from the web and not when running mxmlc. Since I wrote the SWO caching code, I was quite certain there wasn't a good reason for this not to be running, and since there was a simple way to turn this on without actually touching Flex code, I created a class that did this to provide to others. This code is not supported by Macromedia, your mileage may vary, etc.

You can download here a jar file that contains one class, flex.tools.FastMxmlc. I've found using FastMxmlc speeds up compilations anywhere from 5% to 200%. This speedup only comes when you have a lot of classes that haven't changed after a previous compilation. It also depends on how many classes you have. If you have more than a couple hundred classes, you could see more than a 200% increase.

The code in FastMxmlc is really trivial, and only has more than three lines in the main method because of a workaround needed to give the right error status on System.exit(). Because of this workaround, you do need to always specify the output file via "-o". Other than that, everything will work just as it does in mxmlc.

Here's a sample Ant snippet for using this jar:

        <!-- location of webroot (and flexlib) -->
        <property name="compile.webroot" value="apps/dev.war" />
        <property name="compile.flexlib" value="${compile.webroot}/WEB-INF/flex" />
        <!-- the file to compile -->
        <property name="compile.file" value="${compile.webroot}/checkinTest.mxml" /> 
        <!-- location for SWF -->
        <property name="compile.swfloc" value="${compile.webroot}/checkinTest.swf" />
        <!-- location of fastmxmlc.jar -->
        <property name="compile.fastmxmlc"
                  value="${compile.flexlib}/lib/fastmxmlc.jar" />

        <!-- compile using FastMxmlc, a simple wrapper over flex.tools.Mxmlc -->
        <java classname="flex.tools.FastMxmlc" fork="true" failonerror="true">
              <pathelement location="${compile.fastmxmlc}"/>
              <fileset dir="${compile.webroot}/WEB-INF/lib" includes="*.jar" />
              <fileset dir="${compile.flexlib}/jars" includes="*.jar" />
          <jvmarg line="-Xms32m -Xmx768m -Dsun.io.useCanonCaches=false"/>
          <arg line="-o ${compile.swfloc} -flexlib '${compile.flexlib}' 
                     -configuration ${compile.flexlib}/flex-config.xml 
                     -webroot ${compile.webroot} ${compile.file}" />

And now the summary, for those who skimmed the above: you can download here a jar file that contains the class flex.tools.FastMxmlc, a simple wrapper over flex.tools.Mxmlc. This is not a Macromedia-supported jar, but you can try it out for speeding up your command-line compilations. Enjoy!

Comments (13)

Hi Brian,

Welcome to blogging. You have started with nice post, I am sure lots of Flex developer going to get benefited by this.


Thanks for the welcome Abdul. Of course I didn't list all the many great Flex blogs in my welcome but yours is another one that has had lots of great info.

Mike Givens:

Just wanted to post a thanks for the info you supplied on the flexcoders list about the webservice endpoint error I was banging my head against. And I'm happy to see another MM Flex guru online.

Brian this is a great breakthrough, I am dealing with compiling times of about 1 minute and 15 seconds. This seems to have dropped it down to 50 seconds.

Question, should the swo file timestamps be changing on every compile?

Glad I can be of help. Kevin, I don't remember offhand whether the SWO system is smart enough to not reexport everything on every compile. This shouldn't be too much of a concern though- I do remember from performance times that the exporting wasn't a large part of the compilation time.

This is really great! No doubt!
But dont we need to focus on file sizes? I think this is still a big issue. I've heard some ideas on excluding classes for compilation and stuff. I'll be focussing on that.! You will hear more some!


really appreaciate ur ideas & approach to share it..

Good to hear people are still getting use out of this code. M. Sibbald, the only way to exclude a class is to not reference it in your SWF. We certainly worry about speed as well as size in the compiler, and we would definitely do things that made the SWF smaller even if it cost more compiler time.

Here's the technote on fastmxmlc that was created after my post:


To be clear, the code above is just for 1.0 or 1.5. 2.0 does not have SWOs but a new, better system for caching class information.


Any hints how can I setup the directive @ContextRoot for mxmlc in this Ant task?

I think adding "-context context" to the parameter list is the way to do this. This is in the documentation for the mxmlc parameters, I believe.

Is this same caching possible for compc?

Brian Deitte:

Hi Clint, looking at the code, it seems likely that it would be possible for compc with a similar hotfix. I can't promise getting to this anytime soon, but I will put it on my todo list.

Sure... if you get some spare time. Just thought I'd ask.

Thanks a lot Brian.. the fastmxmlc util is awesome.