views:

340

answers:

4

... 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?

+2  A: 

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).

DannySmurf
Or less optimization, if a loop that was unrolled get left alone now...
dmckee
This is pretty much our current guess as well. As an aside, there may be loops in the code we are importing, but we don't actually have any loops, it's all event driven with a very few actual events. We did add a timer for use in time-out checking.
Aaron H.
A: 

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

Miki Watts
That would not account for more than a 4K difference (that is the maximum normal cluster size on a NTFS disk). Also, the fact that it's a 20K difference across different operating systems leads to the conclusion that it is flash related, not system-related.
DannySmurf
Miki, that is one of the first places one would look. I didn't make clear that we had ruled that out. To others, I don't think that answer warrants a down vote.
Aaron H.
A: 

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!

grapefrukt
Neither is true, the only modification to the build flags was the addition of the swc library file.
Aaron H.
A: 

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.

rmeador