私は、非常にテンプレート化されたC ++ライブラリであるSTAPLプロジェクトに取り組んでいます。たまには、コンパイル時間を短縮するためにすべての手法を再検討する必要があります。ここでは、私たちが使用するテクニックをまとめました。これらのテクニックのいくつかは、すでに上記にリストされています。
最も時間がかかるセクションを見つける
シンボル長とコンパイル時間の間に実証済みの相関関係はありませんが、平均シンボルサイズを小さくすると、すべてのコンパイラでコンパイル時間を改善できることがわかっています。したがって、最初の目標は、コード内で最大のシンボルを見つけることです。
方法1-サイズに基づいて記号を並べ替える
nmコマンドを使用して、サイズに基づいてシンボルを一覧表示できます。
nm --print-size --size-sort --radix=d YOUR_BINARY
このコマンドでは--radix=d、サイズを10進数で表示できます（デフォルトは16進数です）。次に、最大のシンボルを見て、対応するクラスを分割できるかどうかを確認し、基本クラスのテンプレート化されていない部分を因数分解するか、クラスを複数のクラスに分割して再設計してみます。
方法2-長さに基づいて記号を並べ替える
通常のnmコマンドを実行し、それをお気に入りのスクリプト（AWK、Pythonなど）にパイプして、長さに基づいてシンボルを並べ替えることができます。私たちの経験に基づいて、この方法は、方法1よりも候補をより良くする最大の問題を特定します。
方法3-Templightを使用する
「Templightは、テンプレートのインスタンス化の時間とメモリ消費をプロファイルし、インタラクティブなデバッグセッションを実行して、テンプレートのインスタンス化プロセスを内省するためのClangベースのツールです。」
Templightをインストールするには、LLVMとClang（手順）をチェックアウトし、Templightパッチを適用します。LLVMとClangのデフォルト設定はデバッグとアサーションにあり、これらはコンパイル時間に大きな影響を与える可能性があります。Templightには両方が必要なようですので、デフォルト設定を使用する必要があります。LLVMとClangのインストールプロセスには、約1時間ほどかかります。
パッチを適用した後templight++、インストール時に指定したビルドフォルダーにあるコードをコンパイルするために使用できます。
それtemplight++がPATHにあることを確認してください。コンパイルするには、次のスイッチをCXXFLAGSMakefileのに追加するか、コマンドラインオプションに追加します。
CXXFLAGS+=-Xtemplight -profiler -Xtemplight -memory -Xtemplight -ignore-system
または
templight++ -Xtemplight -profiler -Xtemplight -memory -Xtemplight -ignore-system
コンパイルが完了すると、同じフォルダーに.trace.memory.pbfと.trace.pbfが生成されます。これらのトレースを視覚化するには、これらを他の形式に変換できるTemplightツールを使用できます。templight-convertをインストールするには、次の手順に従います。通常、callgrind出力を使用します。プロジェクトが小さい場合は、GraphViz出力を使用することもできます。
$ templight-convert --format callgrind YOUR_BINARY --output YOUR_BINARY.trace
$ templight-convert --format graphviz YOUR_BINARY --output YOUR_BINARY.dot
生成されたcallgrindファイルは、kcachegrindを使用して開くことができます。ここでは、最も時間とメモリを消費するインスタンス化を追跡できます。
テンプレートのインスタンス化の数を減らす
テンプレートのインスタンス化の数を減らすための正確な解決策はありませんが、役立ついくつかのガイドラインがあります。
複数のテンプレート引数を使用してクラスをリファクタリングする
たとえば、クラスがある場合、
template <typename T, typename U>
struct foo { };
そして、の両方TとU10の異なるオプションを持つことができ、これを解決するために、あなたが100に、このクラスの可能なテンプレートのインスタンス化を増加している一つの方法は、抽象に別のクラスへのコードの共通部分です。もう1つの方法は、継承の逆転（クラス階層の逆転）を使用することですが、この手法を使用する前に、設計目標が損なわれていないことを確認してください。
テンプレート化されていないコードを個々の翻訳単位にリファクタリングする
この手法を使用すると、共通セクションを一度コンパイルして、後で他のTU（翻訳単位）とリンクできます。
externテンプレートのインスタンス化を使用する（C ++ 11以降）
クラスのすべての可能なインスタンス化がわかっている場合は、この手法を使用して、すべてのケースを別の翻訳単位でコンパイルできます。
たとえば、次の場所にあります。
enum class PossibleChoices = {Option1, Option2, Option3}
template <PossibleChoices pc>
struct foo { };
このクラスには3つのインスタンス化が考えられます。
template class foo<PossibleChoices::Option1>;
template class foo<PossibleChoices::Option2>;
template class foo<PossibleChoices::Option3>;
上記を翻訳単位に入れ、ヘッダーファイルのクラス定義の下にexternキーワードを使用します。
extern template class foo<PossibleChoices::Option1>;
extern template class foo<PossibleChoices::Option2>;
extern template class foo<PossibleChoices::Option3>;
この手法は、インスタンス化の共通セットを使用して異なるテストをコンパイルする場合に時間を節約できます。
注：MPICH2は、この時点での明示的なインスタンス化を無視し、インスタンス化されたクラスを常にすべてのコンパイル単位でコンパイルします。
Unityビルドを使用する
ユニティビルドの全体的な考え方は、使用するすべての.ccファイルを1つのファイルに含め、そのファイルを1回だけコンパイルすることです。この方法を使用すると、さまざまなファイルの共通セクションの再インスタンス化を回避でき、プロジェクトに多くの共通ファイルが含まれている場合は、おそらくディスクアクセスも節約できます。
例として、3つのファイルfoo1.cc、foo2.ccがfoo3.ccあり、それらすべてがSTLtupleからインクルードされていると仮定します。次のようなを作成できます。foo-all.cc
#include "foo1.cc"
#include "foo2.cc"
#include "foo3.cc"
このファイルをコンパイルするのは1回だけであり、3つのファイル間の一般的なインスタンス化を減らす可能性があります。一般に、改善が有意であるかどうかを予測することは困難です。しかし、明らかな事実の1つは、ビルドで並列処理が失われることです（3つのファイルを同時にコンパイルすることはできなくなります）。
さらに、これらのファイルのいずれかに大量のメモリが使用されると、コンパイルが完了する前に実際にメモリ不足になる可能性があります。GCCなどの一部のコンパイラでは、メモリ不足のためコンパイラにICE（内部コンパイラエラー）が発生する場合があります。そのため、長所と短所をすべて理解していない限り、この手法を使用しないでください。
プリコンパイル済みヘッダー
プリコンパイル済みヘッダー（PCH）は、ヘッダーファイルをコンパイラーが認識できる中間表現にコンパイルすることにより、コンパイル時間を大幅に節約できます。プリコンパイル済みヘッダーファイルを生成するには、通常のコンパイルコマンドでヘッダーファイルをコンパイルするだけです。たとえば、GCCの場合：
$ g++ YOUR_HEADER.hpp
これは、生成されますYOUR_HEADER.hpp.gch file（.gch同じフォルダにGCCでPCHファイルの拡張子です）。これは、YOUR_HEADER.hpp他のファイルにインクルードする場合、コンパイラーは以前に同じフォルダーにではYOUR_HEADER.hpp.gchなく自分を使用することを意味しYOUR_HEADER.hppます。
この手法には2つの問題があります。
- プリコンパイルされるヘッダーファイルが安定していて変更されないことを確認する必要があります（makefileはいつでも変更できます）。
- （ほとんどのコンパイラでは）コンパイル単位ごとにPCHを1つだけ含めることができます。つまり、プリコンパイルするヘッダーファイルが複数ある場合は、それらを1つのファイルに含める必要があります（例：）
all-my-headers.hpp。しかし、それはすべての場所に新しいファイルを含める必要があることを意味します。幸い、GCCにはこの問題の解決策があります。-include新しいヘッダーファイルを使用して提供します。この手法を使用して、異なるファイルをカンマで区切ることができます。
例えば：
g++ foo.cc -include all-my-headers.hpp
名前のない名前空間または匿名の名前空間を使用する
名前なし名前空間（別名匿名名前空間）は、生成されるバイナリサイズを大幅に削減できます。名前空間は内部リンケージを使用しています。つまり、これらの名前空間で生成されたシンボルは、他のTU（翻訳またはコンパイル単位）からは見えません。コンパイラは通常、名前のない名前空間に一意の名前を生成します。これは、ファイルfoo.hppがある場合、
namespace {
template <typename T>
struct foo { };
} // Anonymous namespace
using A = foo<int>;
そして、あなたはたまたまこのファイルを2つのTU（2つの.ccファイルに含め、それらを別々にコンパイル）に含めます。2つのfooテンプレートインスタンスは同じではありません。これは、One Definition Rule（ODR）に違反しています。同じ理由で、名前のない名前空間をヘッダーファイルで使用することはお勧めしません。.ccバイナリファイルにシンボルが表示されないように、ファイルで自由に使用してください。場合によっては、.ccファイルのすべての内部詳細を変更すると、生成されるバイナリサイズが10％減少することがわかりました。
可視性オプションの変更
新しいコンパイラでは、動的共有オブジェクト（DSO）でシンボルを表示または非表示に選択できます。理想的には、可視性を変更すると、コンパイラーのパフォーマンス、リンク時最適化（LTO）、および生成されるバイナリー・サイズが改善される可能性があります。GCCのSTLヘッダーファイルを見ると、広く使用されていることがわかります。可視性の選択を可能にするには、関数ごと、クラスごと、変数ごと、さらに重要なことにはコンパイラごとにコードを変更する必要があります。
可視性の助けを借りて、生成された共有オブジェクトから非公開と見なすシンボルを非表示にすることができます。GCCでは-visibility、コンパイラのオプションにデフォルトまたは非表示を渡すことにより、シンボルの可視性を制御できます。これはある意味で名前のない名前空間に似ていますが、より複雑で煩わしい方法です。
ケースごとの可視性を指定する場合は、関数、変数、およびクラスに次の属性を追加する必要があります。
__attribute__((visibility("default"))) void foo1() { }
__attribute__((visibility("hidden"))) void foo2() { }
__attribute__((visibility("hidden"))) class foo3 { };
void foo4() { }
GCCのデフォルトの可視性はデフォルト（パブリック）です。つまり、上記を共有ライブラリ（-shared）メソッドとしてコンパイルするfoo2と、クラスfoo3は他のTU foo1からfoo4は見えなくなります（そして表示されます）。でコンパイルすると-visibility=hidden、foo1表示されるだけになります。foo4隠されることさえあります。
可視性の詳細については、GCC wikiを参照してください。