3

... 私はいくつかの理論に取り組んでいますが、他の意見を聞くことに興味があります。

これは、3 つの異なるマシン (2 つの Windows ともう 1 つの Linux) で確認されています。使用されるコンパイラは、flexbuild (おそらく mxmlc) と ant with mxmlc です。

小さなスタンドアロンの単一 .as ファイル プロジェクトにコードを追加したところ、コンパイルされた swf ファイルのサイズは、Linux ボックスで 32k から 12k に 20k 減少しました。Windows ボックスでは、27k から 8.5k までわずかに異なります。

カスタム ツールを使用して、両方のバージョンがネイティブの swf 圧縮を使用していること、大規模な追加のメタデータがないことを確認しました。Ant ビルド スクリプトへの唯一の変更は、swc ファイルをビルドに追加することです。

コードの削除なし（インポートの削除なし、変数の削除なし、nada）、追加のみで非常にシンプル、ステージにいくつかのコンポーネントが追加され、有効になり、いくつかの小さな関数などが変更され、ループが変更されず、明らかなことは何もありませんコードが少なくなります。

ソース管理を使用して古いバージョンをビルドすると、依然としてファイルが大きくなるため、ライブラリまたはコンパイラの変更ではないようです。

どのコードも Flex コンポーネントを使用しておらず、単純な「flash.etc...」タイプのインポートのみです。

誰もこのような行動を見たことがありますか？これは何が原因だと思いますか？

4

4 に答える 4

2

以前に .NET アセンブリでこの動作を見たことがあります。

この動作についての私の推測では (どこで発生しても)、追加されるものは何でも、コンパイラーは以前よりも多くの最適化を行うことができます。

なぜそれがコンパイラの内部動作について私が持っているよりもはるかに詳細な知識を必要とするのか (そしてなぜこれが起こっているのか - これが実際にここでの原因である場合 - あなたの場合、アドビによってのみ十分に説明される可能性があります)エンジニア）。

于 2008-10-27T19:30:54.720 に答える
0

これと同じ行動を以前にも見たことがあります。最適化と圧縮という 2 つの要因の組み合わせだと思います。新しいコードにより、オプティマイザーが別の方法で処理できるようになる可能性があります (または、直感的には、以前に実行していたある種のインライン化またはループ展開が妨げられる可能性があります)。すべてのフラッシュファイルが圧縮されているため、存在する追加のデータが圧縮のより良い候補になった可能性が高いと思います。そのため、圧縮がより効率的でした. どちらの理論も、半ば知識に基づいた推測にすぎません。

于 2008-10-27T20:58:45.027 に答える
0

推測ですが、ファイルがこれほど小さい場合、ハード ドライブ セクターのたるみが見られるのではないでしょうか?

于 2008-10-27T19:34:18.457 に答える
0

私の最初の予感は、最初の swf が大量の情報を追加するデバッグ モードでコンパイルされたということです。そうでない場合は、2 番目のものは -optimize=true でコンパイルされたと思います。

しかし、どちらも当てはまらない場合は、非常に興味深いものです。

于 2008-10-27T20:20:27.740 に答える