Добавлен код, размер SWF стал ... меньше?

Question

... Я работаю над парой теорий, но мне интересно услышать другие мнения.

Это было проверено на трех разных машинах, на двух окнах на другом linux. Используемый компилятор - это flexbuild (предположительно mxmlc) и ant с mxmlc.

Мы добавили код к небольшому автономному проекту с одним файлом .as, и размер скомпилированного SWF-файла уменьшился на 20 КБ, с 32 КБ до 12 КБ в Linux. Немного по-другому на окнах окна, от 27К до 8,5К.

С помощью специального инструмента мы убедились, что в обеих версиях используется собственное сжатие SWF, без массивных дополнительных метаданных, единственное изменение в сценарии сборки ant - добавление файла SWC в сборку.

Без удаления кода (без импорта импорта, без удаления переменных, nada), только добавление и довольно простое, пара компонентов добавлена ​​на сцену, включена, пара небольших функций и т. Д., Циклы не изменены, ничего очевидного, что привело бы к меньшему количеству кода.

Использование управления исходным кодом для создания старой версии по-прежнему приводит к увеличению размера файла, поэтому в библиотеках или компиляторе это не меняется.

Ни один из кодов не использует компоненты Flex, только прямой импорт типа "flash.etc ...".

Кто-нибудь видел такое поведение? Как вы думаете, что может вызвать это?

Answer 1

Видел такое поведение в сборках .NET раньше.

Мое предположение об этом поведении (где бы оно ни происходило) состоит в том, что все, что будет добавлено, позволяет компилятору выполнять больше оптимизации, чем могло бы быть раньше.

Почему это могло бы потребовать гораздо более подробного знания внутренней работы компиляторов, чем у меня (и почему это может происходить - если это на самом деле причина здесь - в вашем случае, вероятно, можно было бы только полностью адекватно объяснить инженером Adobe).

Answer 2

Я видел такое же поведение и раньше. Я предполагаю, что это сочетание двух факторов: оптимизация и сжатие. Вполне возможно, что ваш новый код позволяет оптимизатору делать что-то по-другому (или, неинтуитивно, предотвращает какое-либо встраивание или развертывание цикла, как это было раньше). Я бы сказал, что более вероятно, что дополнительные данные сделали его лучшим кандидатом на сжатие, так как все файлы флэш-памяти сжаты, так что это было более эффективно при сжатии. Обе теории являются лишь полуобразованными догадками.

Answer 3

Моим первым предположением будет то, что первый swf был скомпилирован в режиме отладки, который добавляет кучу информации. Если это не так, то я думаю, что второй был скомпилирован с -optimize = true.

Но если ни один из них не подходит, это действительно очень интересно!

Answer 4

Я просто догадываюсь, но когда дело доходит до файлов такого маленького размера, может быть, вы видите слабину в секторах жесткого диска?