Websocket サーバーに接続し、メッセージを送受信する Websocketpp クライアントを使用する非常に基本的な EXE を作成しました。私はVS 2013を使用しました。
EXE のサイズが非常に大きいことに気付きました。リリース用に 2.3 MB、デバッグ用に 6 MB のようです。
EXEのサイズを減らす方法について何かアイデアはありますか??
Websocket サーバーに接続し、メッセージを送受信する Websocketpp クライアントを使用する非常に基本的な EXE を作成しました。私はVS 2013を使用しました。
EXE のサイズが非常に大きいことに気付きました。リリース用に 2.3 MB、デバッグ用に 6 MB のようです。
EXEのサイズを減らす方法について何かアイデアはありますか??
WebSocket++ の作成者はこちら。あなたが引用したサイズは、ほぼ正しい球場のようです. echo_server (Linux で ~1MB の実行可能ファイルを生成する) のような「非常に基本的なサンプル」は、プログラム ソースの ~50 行に基づいて考えるよりもはるかに多くのことを行うことに注意してください。
すぐに使える WebSocket++/Asio ベースのプログラムは、高性能のイベント ベースのクライアント/サーバー システムであり、DNS 解決、IPv4 および IPv6、タイマー、SHA1/MD5 ハッシュ、base64 エンコーディング、UTF8 検証、ロギング、スレッド セーフ、およびURI、HTTP、および複数の WebSocket プロトコル バージョンのパーサー。これらの機能を使用してメッセージをエコー バックするだけだからといって、これが単純なプログラムになるわけではありません。
トピックに関するいくつかの観察/メモ:
テンプレートの動作方法により、WebSocket++、ASIO、および STL のコードは、外部にリンクされたライブラリに置かれるのではなく、プログラムにコンパイルされます。これにより、WebSocket++ または Asio プログラムが、外部ライブラリにリンクするプログラムよりも人為的に大きく見える場合があります。
#1 で説明した状況は、外部ライブラリよりも効率的な場合があります。これは、このプログラムが、ライブラリのすべての部分ではなく、コードが実際に使用する部分のみを含むためです。つまり、クライアント エンドポイントをインスタンス化しない場合、クライアント コードは含まれません。構成で TLS 暗号化、ロギング、またはスレッド セーフ機能が無効になっている場合、それらも含まれません。繰り返しますが、テンプレートの動作方法により、これは両方の方向に進む可能性があります。例: クライアントとサーバーの両方を含むプログラムには、不必要な重複が含まれている可能性があります。
WebSocket++ のコードのサイズは、使用するさまざまなエンドポイント構成の数と、それらの各構成で有効になっているオプションに大きく関係しています。これらは、プログラムが他に何を行っても、固定サイズを表します。プログラムがほとんど何もしない場合、それらはコードの大部分を占めます。プログラムが多くのことを行う場合、その割合は縮小します。
WebSocket++ はかなりモジュール化されています (ただし、これは現在あまり文書化されていません)。コードサイズ (おそらく小さな組み込みシステム?) が本当に心配で、Asio と WebSocket++ がすぐに使えるすべての機能を実際に必要としない場合は、多くの機能を削除するか、それらを置き換えるカスタム構成をセットアップできます。独自のスペース最適化実装。
ロギングなしの保証されたシングル スレッド プログラムで、DNS ルックアップもセキュリティ タイムアウトもなしに、1 つの非 TLS 接続のみをサービスする必要があるとします。Asio が行うすべてのものを含まないネイティブ OS ソケット ライブラリに基づいて、独自のネットワーク トランスポート ポリシーを実装できます。必要のないロック/同時実行およびロガー ポリシーをスタブ化することもできます。