Added code, swf size got … smaller?

Question

... I'm working on a couple of theories, but I'm interested to hear other opinions.

This has been verified on three different machines, two windows the other linux. The compiler used is flexbuild (Presumably mxmlc) and ant with mxmlc.

We added code to a small stand-alone single .as file project and the compiled swf file size went down by 20k, from 32k to 12k on the linux box. Slightly different on the windows box, from 27k to 8.5k.

With a custom tool we've verified that both versions are using native swf compression, no massive additional metadata, the only modification to the ant build script is to add an swc file to the build.

No removal of code (No import removals, no variable removals, nada), only addition and pretty simple at that, a couple of components added to the stage, enabled, a couple of small functions, etc, no loops modified, nothing obvious that would result in less code.

Using source control to build the old version still results in a larger file, so it doesn't appear to be a change in the libraries or compiler.

None of the code is using Flex components, just straight "flash.etc..." type imports.

Has anyone seen behavior like this? What do you think might cause this?

Answer 1

Have seen this behaviour in .NET assemblies before.

My guess about this behaviour (wherever it occurs) is that whatever gets added allows the compiler to do more optimizing than it could have previously.

Why that might be would require much more detailed knowledge of the inner workings of compilers than I have (and why this may be happening -- if this is actually the cause here -- in your case could probably only be fully adequately explained by an Adobe engineer).

Answer 2

I'm just guessing, but when it comes to files this small, maybe you're seeing the slack from the hard drive sectors?

Answer 3

My first hunch would be that the first swf was compiled in debug mode that adds a bunch of info. If that's not the case then I'd guess that the second one was compiled with -optimize=true.

But if neither of those are the case it is indeed very interesting!

Answer 4

I've seen this same behavior before as well. I assume it is a combination of two factors: optimization and compression. It is possible your new code allows the optimizer to do things in a different way (or, unintuitively, prevents some kind of inlining or loop unrolling that it was doing before). I'd say it's more likely that the additional data present made it a better candidate for compression, as all flash files are compressed, so it was more efficient at compacting it. Both theories are just semi-educated guesses.