問題タブ [compilation-time]

コミットごとに、buildbot で 2 つの C++ プロジェクトをコンパイルしています。どちらも約 1000 ファイルで、1 つは 100 kloc、もう 1 つは 170 kloc です。コンパイル時間は、gcc (4.4) と Visual C++ (2008) では大きく異なります。

1 つのプロジェクトの Visual C++ コンパイルには 20 分かかります。プロジェクトは他のプロジェクトに依存しているため、複数のコアを利用することはできません。最終的に、32 ビットと 64 ビットで、デバッグとリリースの両方のプロジェクトを完全にコンパイルするには、2 時間半以上かかります。

1 つのプロジェクトの gcc コンパイルには 4 分かかります。4 コアで並列化でき、約 1 分 10 秒かかります。2 つのプロジェクトの 4 つのバージョン (デバッグ/リリース、32/64 ビット) の 8 つのビルドはすべて、10 分未満でコンパイルされます。

Visual C++ のコンパイル時間はどうなっていますか? それらは基本的に5倍遅いです。

C++ kloc のコンパイルに予想される平均時間は? 私のものは、vc++ で 7 s/kloc、gcc で 1.4 s/kloc です。

Visual C++ でコンパイル時間を短縮するためにできることはありますか?

Boost.Asio は優れたライブラリですが、コンパイル時間が非常に遅いという大きな欠点が 1 つあります。HTTP プロトコル (約 1,000 行のコード) の単純な実装 (非常に単純) を GCC 4.4 でコンパイルするには、約 13.5 秒かかります!

PCH を使用しようとしましたが、コンパイル時間はあまり改善されません (約 1 秒のみ)。

Boost.Asio のコンパイル時間を短縮する方法に関するチュートリアルはありますか?

たとえば、どのクラスにどのヘッダーを正確に含める必要がありますか。

たとえばio_service、tcp::ip::sockets、 、tcp::ip::acceptor、deadline_timer、バッファ、および 、 などのいくつかの関数async_readを使用しasync_writeます。

助言がありますか？

PS: できる限りニキビを使用します。

最近の Tex/Latex のシステムでさえ、後の実行を高速化するためにキャッシュを使用しないのはなぜだろうか。1 つのコンマ* を修正するたびに、Latex を呼び出すのにほぼ同じ時間がかかります。これは、すべての画像ファイルを読み込んで変換する必要があるためです。

(* 小さなコンマを変更するだけでも構造全体に影響を与える可能性があることはわかっていますが、もちろん、適切に記述されたキャッシュ形式がその影響を確認できます。また、高速である限り、100% の正確性が必要とされない状況もあるかもしれません。 .)

Tex の言語には、これを複雑または不可能にする何かがありますか? それとも、Tex の元の実装では、これが必要なかっただけですか?

しかし一方で、これが他の人々をあまり悩ませず、ある種のキャッシング (または Tex ファイルをより高速に解析できる形式への透過的な変換)を持つfork を開始したのはなぜでしょうか?

以降の Latex の実行を高速化するためにできることはありますか? すべてのものを chapterXX.tex ファイルに入れてからコメントアウトする以外は?

フラグを使用してGoogleTestフレームワークで実行されるテストを制限することは素晴らしいことですが、私の場合、テストを書いている間、テストプロジェクト全体が何度もコンパイルされるのを待つことにほとんどの時間が無駄になります。

現在作業しているテストケースだけにコンパイルを制限する簡単な方法はありますか？

（VSからテストcppファイルとリソースcppファイルを削除することは常に代替手段ですが、それは多くの作業です...）

Clojure にはどのような種類の安全な言語構成要素があるのでしょうか?

Luke VanderHart と Stuart Sierra による「Practical Clojure」を数回読んだことがありますが、Clojure は (他の Lisp と同様に) コンパイル時の検証チェックを真剣に受け止めていないという明確な印象を今でも持っています。型安全性は、正しいセマンティクスのコンパイル時のチェックを行うための (非常に一般的な) 戦略の 1 つにすぎません

私がこの質問をしているのは、私が間違っていることを証明したくてたまらないからです。文字列を期待する関数が整数のリストなどで呼び出されないことを (実行時ではなくコンパイル時に) 検証するために、clojure で利用できる設計パターンにはどのようなものがありますか?

また、Paul Graham のような非常に賢明な人々が Lisp を公然と提唱し、その上に低レベル言語からすべてを実装できるようにすることを読んだことがあります (ほとんどの人は、言語自体がその上に再実装されていると言うでしょう)。本当なら、型チェックのようなものは簡単にできるはずです。clojure や他の Lisp に型システム (またはそのような型システムを実装する機能) が存在すると思いますか?それによって、プログラマーは検証チェックを実行時からコンパイル時、さらには設計時までオフセットすることができます。時間？

私はいくつかのクラスを持っています。今のところ、それらは 1 つの記号で区切られています。type(a ) を含むものはほとんどなく、含まtypedefないものもほとんどありません。

次のような方法でSFINAEクラスを実装したいと思います。

1 つの方法は、前のリンクに示されているように基本的な SFINAE を使用して、Tに a が含まれているかどうかをチェックしてからチェッカーtypeを使用することです。bool例えば、

デモ。

質問: コード全体にそのようなインスタンスが多数ありますが、この方法ではコンパイル時間が大幅に長くなる可能性があると感じています。1 回目はフラグを見つけtype、2 回目はフラグを解決しboolます。

コンパイル時間を短縮するためのより速い方法はありますか?

[補足: この場合、 との間にtype区切り文字を入れました。ただし、から分離するものは自由に中に入れることができます。それにまつわるアイデアも大歓迎です。】ABAB

Delphi XE2 では、自動生成されたビルド番号機能が、次のような日付と時刻で生成された値を使用するようになりました。

2.4.4386.838

最後の 2 つの数字はビルドするたびに変わり、現在の日付と時刻に基づいています。

リリース番号とビルド番号のこの新しい形式は、非常によく似たことを行う .NET 実装から借用したものだと思います。.net では、最後の数値 (ビルド) は、現地時間の午前 0 時からの秒数を 2 で割った値に等しくなります。.net 実装の詳細については、このリンクを参照してください: Determining Build Date the hard way

これがこの方法を維持するために信頼できる場合、コンパイル時間を決定するより良い方法があります。

1. IDE プラグインの使用

2. PE ヘッダー ハックの使用

問題は、古い自動インクリメント バージョン番号機能に戻る方法ではありません。

問題は、2010 年 1 月 1 日から始まり、ビルド番号とリリース番号に日と秒を追加して、上で示したように XE2 が本当に日付と時刻を使用するかということです。

Eclipseからエクスポートしている実行可能なJARファイルのコンパイル時間を取得しようとしています。これを行う1つの方法は、META-INF/MANIFEST.MFファイルの変更時刻を取得することです。残念ながら、この情報を取得する方法を見つけることができないようです（マニフェスト自体を使用して読み取る方法は知っていますがgetResourceAsStream("/META-INF/MANIFEST.MF")、変更時刻を読み取ることができないようです）。

誰かがそれを行う方法についていくつかの洞察を持っていますか？

main.cpp次のプリコンパイル ヘッダーを含むプロジェクトがあります。

プロジェクトが の場合、*.lib常に正常にビルドされます。

プロジェクトが次の場合*.exe:
でビルドするとCreate (/Yc)、すべて問題ありません。
設定Use (/Yu) 時にリンカーエラーが発生 LNK2001します：

1) 未解決の外部シンボル "private: static class boost::asio::detail::tss_ptr::context> boost::asio::detail::call_stack::top_" (?top_@?$call_stack@Vstrand_impl@strand_service@ detail@asio@boost@@E@detail@asio@boost@@0V?$tss_ptr@Vcontext@?$call_stack@Vstrand_impl@strand_service@detail@asio@boost@@E@detail@asio@boost@@@234@ A)

2) 未解決の外部シンボル "public: static class boost::asio::detail::service_id boost::asio::detail::service_base::id" (?id@?$service_base@Vselect_reactor@detail@asio@boost@ @@detail@asio@boost@@2V?$service_id@Vselect_reactor@detail@asio@boost@@@234@A)

3) 未解決の外部シンボル "public: static class boost::asio::detail::service_id boost::asio::detail::service_base::id" (?id@?$service_base@Vstrand_service@detail@asio@boost@ @@detail@asio@boost@@2V?$service_id@Vstrand_service@detail@asio@boost@@@234@A)

4) 未解決の外部シンボル "public: static class boost::asio::detail::service_id > > boost::asio::detail::service_base > >::id" (?id@?$service_base@V?$deadline_timer_service @Vptime@posix_time@boost@@U?$time_traits@Vptime@posix_time@boost@@@asio@3@@asio@boost@@@detail@asio@boost@@2V?$service_id@V?$deadline_timer_service@Vptime @posix_time@boost@@U?$time_traits@Vptime@posix_time@boost@@@asio@3@@asio@boost@@@234@A)

ブースト: v1_49 静的 /MTd

テンプレートベースのクラス（STLおよびブースト）にソースファイルを使用せず、実装をヘッダーに配置することも一般的な慣習のようです。これにより、ヘッダーとソースファイルでの宣言と実装の従来の分離と比較して、ヘッダーを含むソースファイルのコンパイルにかかる時間が大幅に増えると思います。これが行われる理由は、おそらく、ソースファイルでコンパイラに使用するテンプレートを指示する必要があるためです。これにより、.aファイルが肥大化する可能性があります。

ライブラリが大きくなるにつれてリンカーもより多くの時間を必要とすると仮定すると、ライブラリヘッダーを含むソースファイルのコンパイルにかかる時間の観点から、どちらのアプローチがより高速になりますか？

1. .cppファイルを使用せず、実装を含むクラス全体をヘッダーに配置します

また

2.ライブラリ自体のソースファイル内でさまざまなタイプのテンプレートを明示的にコンパイルします