17

大規模なプロジェクトでは、多数 (数千) のクラスがあり、それぞれに特別なスマート ポインター型が typedef を使用して定義されます。このスマート ポインター型はテンプレート クラスです。「gcc -Q」でコンパイルすると、各クラスのこれらのスマート ポインターのコンパイルに多くの時間が費やされていることがわかります。つまりsmartptr<class1>::methods, then smartptr<class2>::methods... smartptr<class2000>::methods、gcc がそれらを処理するときに画面がスクロールするのが見えます。

このプロセスをスピードアップするためのトリックはありますか? これらのクラスは、smartptr の観点からはすべて同じであり、enable_if トリックなどはありません。

私が今しようとしていること：

  • おそらく、いくつかの一般的なメソッドを使用して、非テンプレートの基本クラスを作成します
  • extern テンプレート クラスを使用してリンク シンボルを削減します (インスタンス化時間はまだわかりません)。

しかし、上記のすべてが完全な解決策ではありません。コンパイル時間を最適化する別の方法、たとえば smartptr を一度解析した場合、生成コードが同じであるため、他の特殊化を見るときに同じ知識を何度も適用できることを gcc に知らせるトリックがあるのではないかと思います。

はい、もちろんまったく同じではないことはわかっています...しかし、それはただのクレイジーなアイデアです。

または、私が気付いていない他のトリックがあり、コンパイルを高速化できる可能性があります。(私が話していることのアイデアを示すために、静的メンバー データのインスタンス化を排除することで、別のテンプレートを最適化することができました。これにより、コンパイル時間が大幅に短縮されました。これはまったく明らかではありませんでした。)

4

2 に答える 2

1

smartptr具体的には GCC ではありませんが、非テンプレートの基本クラスから派生させるというアイデアは良い賭けのように思えます。スマート ポインターは、このアプローチに適した候補です。繰り返し生成されるコードの多くは、ポインターがvoid*. (クラス テンプレートが必要に応じてキャストしたりキャストしたりするだけのことを行うように、できるだけ多くのコードを移動しますvoid*。)

また、 に大きく依存しているクラスが何千もある場合はsmartptr、この方法で問題の芽を摘むことを最初に検討する必要があります。それが失敗した場合にのみ、smartptrのクライアント コードに進みます (その時点で、一般的なヘッダーの肥大化を回避するための手法を検討する価値があります)。

extern テンプレート宣言に関しては、私はこれらの経験はありませんが、 extern.per ごとに宣言を追加する必要があるように思えますtypedef。特に、完全なインスタンス化を強制する逆の効果は、次のように実行されます。

template class smartptr<MyClass>;

この行があなたのいずれにも付随していないことを再確認しますtypedef!

于 2013-01-11T08:58:04.883 に答える
0

プリコンパイル済みヘッダー

コードの変更がヘッダーに含まれていない場合、コンパイル時間の短縮に役立つ可能性があります。 (ソース)

于 2012-12-29T16:18:23.693 に答える