アカウント名:
パスワード:
makeだと通常1ファイルごとにコンパイラーを起動するから数が多いと遅くなるね。
Visual Studioは複数のファイルをまとめて一度にコンパイルしている模様で、コンパイラーの起動・終了オーバーヘッドが相対的に小さいとか、PCHの内容をメモリ内で使いまわしてるとか、その辺りの手法で差が出ているかも。
gcc でも 3.4 からプリコンパイル機能が追加されています。a.h をコンパイルすると a.h.gch というファイルができて、以後 a.h を include するときに a.h.gch が優先的に読み込まれます。
他所様のソースをプリコンパイル向けに最適化するのは難しいですが、ゼロから作るならプリコンパイル対応にするのも良いかもしれません。
試しに 11 ファイル(ソース 6000行、ヘッダ 800 行)からなる plain C のプロジェクトをコンパイルした結果を置いておきます。OS は FreeBSD 6 RELEASE、プリコンパイルヘッダはあらかじめ作成しておき、全ファイルをコンパイルしています。
プリコンパイルヘッダなし$ time makereal 2.919suser 2.672ssys 0.225s $ time make -j2real 2.956suser 2.751ssys 0.191s プリコンパイルヘッダあり$ time makereal 1.913suser 1.759ssys 0.142s $ time make -j2real 1.953suser 1.789ssys 0.151s
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
PCH (スコア:2, 参考になる)
プリコンパイル済ヘッダーやインクリメンタル・コンパイル、インクリメンタル・ビルドなどで、2回目以降が速いです。
それが逆にトラブルの原因にもなることもあったりもしますが。
久しぶりにFreeBSDに戻ってみて愕然としました。
makeが-jで並列に処理するのには感心しましたが、しかし、ソースファイルが短いのにコンパイルが遅い。
1クラス1ファイルとか、1関数1ファイルなのに、けっこうな時間がかかる。
それらのファイル群を片っ端から#includeして1ファイルに纏め上げたら、速いのなんのって。
make -jすればディスクアクセスがランダムになりやすいのでSSDで高速化するでしょうが、
それは乱暴なソリューションかもしれません。
Re:PCH (スコア:2)
Re:PCH (スコア:2)
makeだと通常1ファイルごとにコンパイラーを起動するから数が多いと遅くなるね。
Visual Studioは複数のファイルをまとめて一度にコンパイルしている模様で、コンパイラーの起動・終了オーバーヘッドが相対的に小さいとか、PCHの内容をメモリ内で使いまわしてるとか、その辺りの手法で差が出ているかも。
Re:PCH (スコア:1)
gcc でも 3.4 からプリコンパイル機能が追加されています。
a.h をコンパイルすると a.h.gch というファイルができて、
以後 a.h を include するときに a.h.gch が優先的に読み
込まれます。
他所様のソースをプリコンパイル向けに最適化するのは難し
いですが、ゼロから作るならプリコンパイル対応にするのも
良いかもしれません。
試しに 11 ファイル(ソース 6000行、ヘッダ 800 行)からな
る plain C のプロジェクトをコンパイルした結果を置いてお
きます。
OS は FreeBSD 6 RELEASE、プリコンパイルヘッダはあらかじ
め作成しておき、全ファイルをコンパイルしています。
Re: (スコア:0)