実際には関数のサイズではなく、実行時にキャッシュされるコードの合計サイズです。コードをより多くの小さな関数に分割しても、それらの関数の一部がクリティカル コード パスでまったく呼び出されず、したがってキャッシュを占有する必要がない場合を除いて、高速化することはできません。さらに、コードを複数の関数に分割しようとすると、コンパイラがそれらをインライン化することを決定した場合、コンパイラによって元に戻される可能性があります。
したがって、現在のコードが「パフォーマンスに影響を与えている」かどうかを判断することは実際には不可能です。コードを別の方法で構造化できた多くの方法のどれと比較してヒットしましたか? そして、そのような変更がパフォーマンスに特定の違いをもたらすと合理的に期待することはできません.
あなたが探しているのは、めったに実行されない命令 (プロファイラーがどれかを教えてくれます) であると思いますが、頻繁に実行される命令のすぐ近くにあります (したがって、キャッシュにある必要があります)多く、それらの周りのキャッシュラインを引き込みます）。よく実行されるコードをまとめてクラスター化できれば、命令キャッシュをさらに活用できます。
ただし、実際には、これはあまり実りの多い最適化の行ではありません。あなたが大きな違いを生む可能性は低いです。他に何もないとしても、一般的に実行されるコードはおそらく非常に小さく、すでに隣接しています。それは、どこかで少数のタイトなループになります (プロファイラーが場所を教えてくれます)。また、最下位レベルのキャッシュ ラインは通常小さい (32 バイトまたは 64 バイト程度) ため、コードを非常に細かく再配置する必要があります。C++ では、ユーザーとオブジェクト コードとの間に多くの隔たりがあり、メモリ内で命令を慎重に配置することが妨げられています。
のようなツールperfは、キャッシュ ミスに関する情報を提供します。それらのほとんどは実行可能コードに関するものではありませんが、ほとんどのシステムでは、回避しているキャッシュ ミスは問題ではありません。コードアップします。多くのミスがない限り、おそらく多くはありませんが、いくつかあります。
とにかく、これはどのような文脈で聞いたのですか？私が聞いた中で最も一般的なのは、関数のインライン化が非生産的であるという考えです。これは、コードの肥大化によるオーバーヘッドが、回避された関数呼び出しのオーバーヘッドよりも大きい場合があるためです。よくわかりませんが、コンパイラがサポートしている場合は、プロファイルに基づく最適化が役立つかもしれません。かなり妥当なプロファイルに基づく最適化は、より多くの回数実行される呼び出しサイトで優先的にインライン化することです。これにより、よりコールドなコードが小さくなり、最初のロードと修正のオーバーヘッドが少なくなり、(できれば) 命令の中断が少なくなります。私よりもはるかに多くのコンパイラの知識を持っている誰かが、それが良いかどうかについて一生懸命考えたでしょう。プロファイルに基づく最適化、したがって、それを実装するかどうかを決定しました。