GCCのプリコンパイル済みヘッダはどの程度有用か
アプリケーションを構築するたびに、同じヘッダファイルの組み合わせをソースにインクルードすることが少なくない。その場合、プリプロセッサは何度も同じヘッダファイルを読み込んで処理することになる。新たに登場するGCCでは、あらかじめヘッダファイルをコンパイルしておくことができるので、プリプロセッサは要求のたびにヘッダファイルを読み込んで処理する必要がなくなる。目的の言語に一致するプリコンパイル済みヘッダがすぐにインクルードされるので、コンパイル時間を短縮することができる。
glibcヘッダをすべてプリコンパイルできれば理想的である。 1つの独立したプログラムは必ずglibcヘッダを必要とするからだ。しかし、言うは易し、行うは難しである。プリコンパイル済みヘッダを作成して使用するのは難解な作業なのだ。ポイントは、アプリケーション自体を作成するときと同じgccコマンドラインオプションを使ってプリコンパイル済みヘッダを作成しなければならないという点である。両者のgccコマンドラインオプションが一致しなければ、プリコンパイル済みヘッダは使用できなくなる可能性が高い。その場合は、通常のヘッダを使用せざるを得ない。問題の核心がここにある。最適化を図るため、通常はアプリケーションによってコマンドラインオプションが異なるのだ（最適化に関するオプションには、-O、-fomit-frame-pointer、-marchなどがある）。glibcヘッダをプリコンパイルできるようにするのは大変なのだ。
技術的には、コンパイルするアプリケーションごとにプリコンパイル済みヘッダ専用のディレクトリを用意することもできる。アプリケーションをコンパイルするたびに、まったく同じgccコマンドラインオプションを使用することが前提条件だ。しかし大きな問題がある。大量のディスク領域が必要になることだ。たとえば、10MBのglibcヘッダをプリコンパイルするには、およそ1GBの空き領域が必要になる。使用するアプリケーションの数が多くなると、専用ディレクトリの管理はとたんに難しくなる。
それでは、プリコンパイル済みヘッダはどの程度有用なのか。アプリケーションにインクルードするプライベートヘッダファイルはすべてプリコンパイルすることができる。アプリケーションに同じプライベートヘッダファイルを何度もインクルードする場合には、そのヘッダファイルをプリコンパイルしておくことで、時間を節約できる可能性が高い。しかし、すべてのアプリケーションが恩恵を受けられるわけではない。とりわけ、ヘッダファイルの数が少ないアプリケーションや、比較的サイズが小さいためにコンパイル時間が短いアプリケーションなどでは、プリコンパイル済みヘッダを使用する利点はあまりない。また、ヘッダのプリコンパイルにかかる時間も軽視できない。ヘッダファイルの数が少なく、その使用頻度も低い場合には、プリコンパイルのためにかえって時間がかかることもある。コンパイル時間を1、2秒短縮することに強い関心を持つ人はあまりいないだろう。
制限事項がいくつかあるものの、ヘッダをプリコンパイルしておくという考え方には、非常に興味をそそられる。既存のパッケージを正しくコンパイルするという観点からすると、現状のGCC-3.4-CVSは特に使いやすいというわけではない。安定したGCC-3.4ブランチがリリースされ、現場できちんとテストできるようになるまでには、まだしばらく時間がかかりそうだ。しかし、さまざまな要素を総合的に判断すると、KDEやQTなどの大規模パッケージの場合、開発者がプリコンパイル済みヘッダを使用できるのは大きなメリットだ。