Добавлен код, размер swf стал ... меньше?
... Я работаю над парочкой теорий, но мне интересно услышать другие мнения.
Это было проверено на трех разных машинах, двух окнах и другом Linux. Используемый компилятор - это flexbuild (предположительно mxmlc) и ant с mxmlc.
Мы кодируем добавлен в небольшой автономный проект с одним файлом .as, и размер скомпилированного SWF-файла уменьшился на 20 КБ, с 32 КБ до 12 КБ в Linux. Немного по-другому на windows box, от 27к до 8,5к.
С помощью специального инструмента мы проверили, что обе версии используют собственное сжатие swf, без массивных дополнительных метаданных, единственная модификация скрипта сборки ant - это добавлять, файл swc для сборки.
Без удаления кода (без удаления импорта, без удаления переменных, нада), только добавление и довольно простое при этом, пара компонентов, добавленных на сцену, включена, пара небольших функций и т.д., никаких циклов не изменено, ничего очевидного, что приведет к меньшему количеству кода.
Использование системы управления версиями для сборки старой версии по-прежнему приводит к увеличению размера файла, поэтому это не похоже на изменение библиотек или компилятора.
Ни в одном коде не используются компоненты Flex, только прямой импорт типа «flash.etc ...».
Кто-нибудь видел подобное поведение? Как вы думаете, что может вызвать это?
Ответы 4
Вы уже видели подобное поведение в сборках .NET.
Я предполагаю, что такое поведение (где бы оно ни происходило) состоит в том, что все, что добавляется, позволяет компилятору делать больше оптимизаций, чем он мог бы сделать раньше.
Почему это может потребовать гораздо более подробных знаний о внутренней работе компиляторов, чем у меня (и почему это может происходить - если это на самом деле причина здесь - в вашем случае, вероятно, может быть полностью адекватно объяснено только Adobe инженер).
Я просто догадываюсь, но когда дело доходит до таких маленьких файлов, может быть, вы видите провисание в секторах жесткого диска?
Это не приведет к разнице более чем в 4 КБ (это максимальный нормальный размер кластера на NTFS-диске). Кроме того, тот факт, что разница в 20 КБ между разными операционными системами, позволяет сделать вывод, что это связано с флэш-памятью, а не с системой.
Мики, это одно из первых мест, куда можно было бы заглянуть. Я не уточнил, что мы это исключили. Для других я не думаю, что этот ответ оправдывает голосование "против".
Моя первая догадка заключалась в том, что первый swf был скомпилирован в режиме отладки, что добавляет кучу информации. Если это не так, я бы предположил, что второй был скомпилирован с -optimize = true.
Но если ни то, ни другое не соответствует действительности, очень действительно интересен!
Это тоже не так, единственной модификацией флагов сборки было добавление файла библиотеки swc.
Я видел такое же поведение раньше. Я предполагаю, что это комбинация двух факторов: оптимизации и сжатия. Возможно, ваш новый код позволяет оптимизатору делать что-то по-другому (или, что неинтуитивно, предотвращает какую-либо инлайнинг или разворачивание цикла, что он делал раньше). Я бы сказал, что более вероятно, что присутствующие дополнительные данные сделали его лучшим кандидатом для сжатия, так как все файлы flash сжаты, поэтому сжатие было более эффективным. Обе теории - лишь полуобразованные догадки.
Это в значительной степени и наше текущее предположение. Кроме того, в коде, который мы импортируем, могут быть циклы, но на самом деле у нас нет никаких циклов, все это связано с очень небольшим количеством реальных событий. Мы добавили таймер для использования при проверке тайм-аута.