Jiri Tobisek's Blog

Many developers, who upgraded their Flex SDK from 3.x.x to 4.x.x have noticed this – the compiler speed seems to have deteriorated, the project build time has grown enormously. In fact, for large projects,  such as the one I am working on, it has become unbearably sluggish. In spite of the incremental compilation and advertised performance tuning, any subtle change means long project rebuilding. In our case, the complete recompile takes almost twice as long with SDK 4.1 compared to SDK 3.5. The compile time of separate modules has grown exponentially. Most curiously, judging from the reactions on the Internet, this frustrating deterioration does not seem to affect all developers. It all looked very weird and puzzling at first.

After having gone through some detective work, I found the culprit. As part of the build process, Flex seems to run recursively through all source directories, hashmapping and timestamping whatever file is in his way. Which is fine, unless your code is part of a SVN repository: every single directory/package of your project thus contains a .svn subfolder with more subfolders and metadata files. Therefore, if you work on large project with lots of packages, Flex SDK 4.x.x (unlike its 3.x.x predecessor) browses and timestamps huge amount of files which technically do not belong to your code at all. The fact that the .svn directories have the hidden flag on does not help a bit. This explains why only part of the developers have been affected – namely, those working on large, complex projects stored in SVN (or possibly CVS or any system which keeps meta data on per-folder basis).

So – what can be done? How the speed of the Flex compiler can be recovered in the SDK 4.x.x? There are several options, and I ultimately went through all of them (well, almost):

1. Migrate to different version control system, such as Git – not feasible in our case, generally not cool
2. Use only command-line compiler – it’s speed is not affected. But forget auto-build, background error checks…
3. Create mirror directory of your project without the SVN meta data and keep it synchronized – very cumbersome
4. Use the HellFire Compiler – solves the problem, but it means additional license cost and also does not work as smoothly as one would wish
5. File a bug report at Adobe – and wait forever before they even notice
6. Download the Flex SDK source code and repair it by yourself

Slowly, we eliminated the first five solutions, before we arrived at the last one. The whole problem can be solved by adding two lines to the /modules/compiler/src/java/flex2/tools/oem/internal/OEMReport.java source file, more precisely to its storeTimestamps(File path) function:

    private void storeTimestamps(File path)
    {

        // the fix is here:
        if(path.isHidden())    
                return;
        // end of the fix
        timestamps.put(FileUtil.getCanonicalPath(path), path.lastModified());

        for (File file : path.listFiles())
        {
            if (file.isDirectory())
            {
                storeTimestamps(file);
            }
        }
    }

Edit and build the source – and you get a freshly baked SDK 4.x.x of your own, with the speed of ol’ good SDK 3.x.x.

As the change seems to affect only one .jar file, you can try to replace directly the <sdk>/lib/flex-compiler-oem.jar with my build (based on SDK 4.1, revision 16076), which can be downloaded here.