Question

... Je travaille sur quelques théories, mais j'aimerais entendre d'autres opinions.

Ceci a été vérifié sur trois machines différentes, deux fenêtres l’autre sous Linux. Le compilateur utilisé est flexbuild (probablement mxmlc) et ant avec mxmlc.

Nous avons ajouté du code à un petit projet de fichier .as autonome et la taille du fichier SWF compilé a été réduite de 20 Ko, passant de 32 Ko à 12 Ko sur le système Linux. Légèrement différent sur la boîte de fenêtres, de 27k à 8,5k.

Avec un outil personnalisé, nous avons vérifié que les deux versions utilisent la compression swf native, pas de métadonnées supplémentaires volumineuses. La seule modification apportée au script ant build consiste à ajouter un fichier swc à la construction.

Pas de suppression de code (pas de suppression d'importation, pas de suppression de variable, nada), ajout simple et assez simple à cela, quelques composants ajoutés à la scène, activé, quelques petites fonctions, etc., aucune boucle modifiée, rien d’évident qui aurait pour résultat moins de code.

L'utilisation du contrôle de code source pour générer l'ancienne version génère toujours un fichier plus volumineux. Il ne semble donc pas y avoir de changement dans les bibliothèques ou le compilateur.

Aucun code n'utilise de composants Flex, mais simplement "& flash; flash.etc ...". type importations.

Quelqu'un a-t-il déjà vu un tel comportement? Selon vous, qu'est-ce qui pourrait causer cela?

Était-ce utile?

La solution

Vous avez déjà vu ce problème dans les assemblys .NET.

Ce que je suppose à propos de ce comportement (quel que soit le cas) est que tout ce qui est ajouté permet au compilateur de faire plus d'optimisation qu'auparavant.

Pourquoi cela pourrait nécessiter une connaissance beaucoup plus détaillée que moi des rouages ??des compilateurs (et pourquoi cela pourrait se produire - si tel est en fait la cause ici - dans votre cas, vous ne pourrez probablement que l'expliquer de manière complète par un ingénieur Adobe).

Autres conseils

Je ne fais que deviner, mais quand il s'agit de fichiers aussi petits, peut-être constatez-vous le jeu des secteurs du disque dur?

Mon premier pressentiment serait que le premier swf a été compilé en mode débogage, ce qui ajoute de nombreuses informations. Si ce n'est pas le cas, je suppose que le second a été compilé avec -optimize = true.

Mais si ce n'est pas le cas, c'est très intéressant!

J'ai déjà vu le même comportement auparavant. Je suppose que c'est une combinaison de deux facteurs: optimisation et compression. Il est possible que votre nouveau code permette à l'optimiseur de faire les choses d'une manière différente (ou, de manière inattendue, empêche toute forme de déroulement en ligne ou de déroulement de boucle qu'il faisait auparavant). Je dirais qu'il est plus probable que les données supplémentaires présentes en fassent un meilleur candidat pour la compression, étant donné que tous les fichiers flash sont compressés, ce qui rend le compactage plus efficace. Les deux théories ne sont que des suppositions semi-éduquées.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top