c - 32ビットマシンのいくつかの小さな値で__int8_tを使用することは、無駄な最適化の努力ですか？

Question

関数には、通常10未満の値がいくつかあります。したがって、intの代わりに__int8_tを使用してこの値を格納する場合、最適化の無駄な努力はありませんか？

Answer 1

これは役に立たない最適化であるだけでなく、整数の不整合（つまり、アーキテクチャに応じて4バイトまたは8バイトの境界に整列されていない整数）を引き起こし、実際にパフォーマンスを低下させる可能性があります。これを回避するために、ほとんどのコンパイラはほとんどのアーキテクチャで整数を整列しようとします。したがって、コンパイラはパディング（スタックベースの変数や構造体メンバーなど）を追加して、より大きな変数や構造体メンバーを適切に整列するため、スペースをまったく節約できない可能性があります。 8ビット整数に従います。あなたの質問は関数内のローカル変数に関するもののように見え、そのような変数は1つしかなく、関数は再帰的ではないと仮定しているため、最適化はおそらく不要であり、プラットフォームのネイティブ整数サイズを使用する必要があります（つまり、 int）。

あなたが言及した最適化は、特定のタイプのインスタンスが非常に多く、構造体の小さな整数に64ビットフィールドではなく8ビットフィールドを使用することで、より少ないメモリを消費したい場合に価値があります。これが意図されている場合は、構造体が最小サイズに適切にパックされるように、プラットフォームに適したプラグマやコンパイラスイッチを使用してください。小さい整数サイズを使用すると便利なもう1つの例は、配列、特に大きい配列が関係している場合です。最後に、型のビット数を指定することは移植性がないことに注意してください。名前の先頭に二重下線が付いているためです。

これはあなたの質問に接線方向にのみ関連しているように見えるので、これについて言及するのは危険ですが、0〜255よりもさらに狭い範囲の値では、構造体の8ビットintよりもさらに小さくすることができます。この場合、ビットフィールドがオプションになります-マイクロ最適化の縮図です。時間と空間のドメインで実際にパフォーマンスを測定し、大幅な節約が確実に行われる場合を除いて、ビットフィールドを使用しないでください。さらにあなたを思いとどまらせるために、私は次の段落でそれらを使用することの落とし穴のいくつかを提示します。

ビットフィールドは、データを可能な限り少ないバイトにパックするように構造体メンバーを手動で順序付けることを強制することにより、開発プロセスをさらに複雑にします。これは、困難であるだけでなく、完全に直感的でない構造体メンバー変数の順序付けにつながることがよくあります。メンバー変数の変更、追加、および削除は、多くの場合、それらに続くメンバーにカスケードされる傾向があり、将来のメンテナンスの問題を引き起こします。この問題を回避するために、開発者はしばしばパディングとアライメントビットを構造体に貼り付け、コードの元の開発者を除くすべての人にとってプロセスをさらに複雑にします。そのようなコードにコメントすることは、良いことではなくなり、しばしば必要になります。開発者がコード内のビットフィールドを処理していることを忘れて、基になるタイプのドメイン全体を持っているかのように扱うという問題もあります。

上記のガイドラインを前提として、アプリケーションのプロファイルを作成し、今説明した最適化が特定のコンパイラーとプラットフォームに適しているかどうかを確認します。

Answer 2

時間の節約にはなりませんが、これらが100万個ある場合は、3 MBのスペースを節約できます（時間の節約になる可能性があります）。