Pay Attention To compc -include-sources
Have you ever used the compc “–include-sources” command-line option (or used this command-line option in Flex Builder Library projects) before?
If your answer is yes, you should know that this command-line option leads the compiler (compc) to use a slower and more memory-intensive algorithm. Why? Before I tell you why, take a look at the two compile algorithms:
The two algorithms are in the batch1() and batch2() methods. The batch1() method is the slower and memory-intensive one. The batch2() method is more complicated but more opportunistic; uses less memory and hence runs faster.
You can see that the algorithm in the batch1() method is more “synchronized”. Basically, the algorithm keeps all the compilation units in the same compilation phase before moving all of them to the next phase. This algorithm was first developed in the early days (pre-beta 3) of the Flex 2 development cycle. During that time, everything (including the AS3 compiler, AVM+) was a moving target. The compiler team needed to provide a relatively stable compiler for the framework team to use on a daily basis. The algorithm was therefore somewhat conservative and it was okay to use a little more memory or run slower.
But why the “–include-sources” command-line option leads the compiler to use the batch1() method?
Well, Flex developers learn from the official Flex documentation that they should put only one public, top-level definition (e.g. classes, functions, variables, namespaces are valid definitions in AS3) in a source file. This is mostly due to the fact that the compiler looks for definitions from the source path based on the names of the files in the source path.
But if you tell the compiler an explicit list of source files to compile (i.e. by using the “–include-sources” command-line option), you are allowed to put multiple, public top-level definitions in any one of those source files. Okay, what’s so nice about putting multiple, public top-level definitions in a source file? Well, I don’t know. Some developers simply want easy source file management by grouping many small classes/functions into a few files (playerglobal.swc is a prime example).
But one not-so-nice thing about these multi-definition source files is that the compiler needs to know what definitions the source files have before trying to look up missing/unresolved definitions from the source path. That means, “parsing” all of them before “analyzing” them. That sounds exactly like what the algorithm in batch1() does!
My advice? If your SWC projects are small, it’s okay to use “–include-sources”. Otherwise, stick with “–include-classes”.