2016-12-02 1 views
-1

目標:シリアルCOMポートから受信したデータフレームを処理するC++のMicrosoft Windowsコンソールアプリケーションでのパフォーマンスに関する質問があります。 Cと組み込みシステム(これは私の経験の大部分があります)では、私は通常コンパイル時に大きなバッファを割り当てます。 しかし、私が今作業しているのは、Windows上で実行される論理プロトコルを使用してシリアルCOMポートを管理するソフトウェアです(上位レイヤソフトウェアは、シリアルバスに接続された組み込みシステムと通信するためにこれと相互作用します) 、RAMとCPUの速度は問題ではありません。私はC++のオブジェクト機能を利用しています。メモリ割り当てのC++パフォーマンスに関するアドバイス

私のしていることは、データフレームを受信すると、フレームタイプ(応答応答、応答応答、応答要求など)、送信元と宛先などのすべての情報を格納できるクラスがあることですノードアドレス、およびペイロード(動的な長さのバッファを0から1024バイトまで動的に割り当てる) 私は現在、プロトコルを処理するクラスの中にヘッダを格納するコンパイル時に5バイトのバッファを割り当てています。一度私は完全な5バイトのヘッダを受け取ると、ペイロードを格納するのに必要なバッファを割り当てるためにペイロードサイズフィールドを使用します。フルフレームが受信されたときは、crc16を計算し、データが有効であることを確認します。すべての情報とペイロードを格納している割り当て済みバッファへのポインタを格納するフレームクラスオブジェクトを作成する(コピーが一度も必要ない)ため、パケットオブジェクトを上記のレイヤーに渡して、オブジェクトデストラクタは、フレームオブジェクトがソフトウェアの上記のレイヤから削除されると、ペイロードを格納しているバッファの割り当てを解除します。 それは良いアプローチですか、私はPCのパフォーマンスを殺していますか? TXスケジューリングは同様の方法で行われます。 アドバイスはありますか?

答えて

0

解決策は問題ありません。実行時にバッファを割り当てることは、サイズがコンパイル時にわからない場合、悪い習慣とはみなされません。また、不必要にバッファをコピーしないように気をつけているようですが、これは良い方法です。

パフォーマンスが心配な人は、TCMallocやJEMallocのようなサードパーティのアロケータを試すことができますが、これは通常、スレッドや断片化されたメモリスペースが多い場合に役立ちます。

これらのバッファーがほぼ同じサイズで、常に割り振りおよび割り当て解除されている場合は、初期化時にバッファー・プールを作成し、new/deleteを呼び出すのではなく実行時にバッファー・プールを要求/

+0

(初期化時にバッファプールを作成し、実行時にnew/deleteを呼び出すのではなくプールに要求/戻ります)、このアプローチは、リソースとCPUが限られているため、埋め込み側で行っています。スピード。私はメモリとCPUの速度が問題ではないので、PC上で異なるアプローチを試みるまでになっていました。ダイナミックアロケーションは私のための新しいもので、実際にはパフォーマンスのボトルネックであることを読んでいました。それがより良い方法であるなら、私は骨董品でした。 TCMallocを試すにはどのヘッダファイルを含める必要がありますか?リファレンスドキュメント?どうもありがとうございます。 – Dominick

+0

@Dominickまず、gprof(https://sourceware.org/binutils/docs/gprof/)のようなコードを使用して、コードのパフォーマンスをプロファイルします。割り当てが実際にユースケースのボトルネックになっているかどうかがわかります。 TCMallocは、Googleが作成した新規/削除の代替品です。こちらをご覧ください(http://goog-perftools.sourceforge.net/doc/tcmalloc.html)。 – Erix