複数のエンティティで使用され、標準の方法でインポートされる Go パッケージを作成すると、すべてのユーティリティが小さいものも含めて、コンパイル時に大きなバイナリが作成されます。問題を調査すると、使用されない関数も含めて、パッケージ全体が各ユーティリティにコンパイルされていることがわかりました。
問題をさらに詳しく調べるには、次の点を考慮してください。 code:
main.go:
package main import "play/subplay" func main() { subplay.A() }
play/subplay.go:
package subplay func A() { fmt.Printf("this is function A()") } func B() { fmt.Printf("secret string") }
にもかかわらず関数B() が呼び出されないと、その文字列値「秘密文字列」がコンパイルされたバイナリ main.exe に表示されます。この動作により、コンパイル時に Go プログラムから未使用のコードをどのように削除するかという問題が生じます。
その答えは、Go コンパイラーがすでにこのタスクを処理しているという事実にあります。コンパイル プロセスでは、コンパイラはコードをアーカイブ ファイル (.a) にパッケージ化し、実行可能バイナリに必須のコンポーネントのみを含めます。到達不能として識別可能な項目は除外されます。
インポートされたパッケージが他のパッケージをインポートする場合、このフィルタリング プロセスを再帰的に適用する必要があることに注意することが重要です。たとえば、追加のパッケージをインポートするパッケージをインポートすると、それらの依存パッケージも含められます。
次にいくつかの例を示します:
機能を使用せずにパッケージをインポートする:
package main import _ "play/subplay" func main() { }
この場合、生成されるバイナリは約 1 MB になります。ただし、インポートされたパッケージが net/http:
package subplay import _ "net/http" func A() {}
をインポートし、コード内で net/http を使用しない場合、net/http のインポートによりバイナリ サイズは約 5 MB に大幅に増加します。他のパッケージは 39 個あります。
そして、net/http の使用を開始しても、メイン パッケージで subplay.A() を呼び出さなかった場合、実行可能ファイルのサイズはそのままになります。同じです。
package subplay import "net/http" func A() { http.ListenAndServe("", nil) }
バイナリ サイズがさらに増加するのは、メイン パッケージから subplay.A() を呼び出すときだけです。
package main import "play/subplay" func main() { subplay.A() }
要点は、コード実行可能バイナリに含まれるファイルは、インポートされたパッケージから呼び出す関数やモジュールによって直接影響を受けます。
さらに、次のことが不可欠です。 Go は静的にリンクされた言語であることを覚えておいてください。つまり、実行可能バイナリには、実行に必要なものがすべて含まれている必要があります。
以上がコンパイル時に Go バイナリから未使用のコードを削除するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。