問題タブ [build-time]

ソリューションの読み込み時間とビルド時間に特に関心があります。ソリューションが少ないほどパフォーマンスが向上しますか?

ビルドされたアプリケーションのパフォーマンスについて言及しているわけではないことに注意してください。

少数のプロジェクトで作業する場合、ロード時間とビルド時間はより効率的ですか?

目安として、Visual Studio ソリューションには 50 ～ 60 のプロジェクトがあります。

gccを使用してファイルを作成するプロジェクトがあります。プロジェクトには、1つの大きなサブプロジェクト（SDK）と、そのSDKといくつかの共有フレームワークを使用する比較的小さなサブプロジェクトが多数含まれています。

プリコンパイル済みヘッダーを使用しますが、これは再コンパイルを高速化するためにのみ役立ちます。

ビルド時の最適化に役立つ既知の手法やツールはありますか？または、このトピックまたは関連トピックに関する記事/リソースを知っていますか？

typedef アプローチがビルドに与える影響に興味があります。

次の例を考えてみてください。

上記のような状況になると、これにより typedef がヘッダー ファイルに書き込まれるため、ヘッダー ファイルに #include する必要があります。前方宣言がないためにビルド時間が長くなる可能性があることを懸念しています。

この投稿のコメントに基づく:

C++ での typedef の前方宣言

クラスを前方宣言し、参照またはポインターを typedef してから、.cpp ファイル内に #include することができます。これにより、ビルド時間が短縮されます。これについての私の結論は正しいですか？

もしそうなら、私は次のような typedef になるでしょう：

これは私には非常にきれいなコードのようには見えません。これを推奨する記事/投稿 (必ずしも SO ではない) を読んだことがあると思います。

これは受け入れられると思いますか？より良い代替案は？

更新:Michael Burr の回答を使用して、ポインターと参照のみのケースを解決できました。ただし、関数で sizeof() を取得しようとしたときに問題が発生しました。たとえば、クラスに次の関数があるとします。

あるいは、これは機能します。

Microsoft Visual C++ 6.0 を使用しています。これはコンパイラのバグですか、それとも一般的に標準に反していますか?

エラーのある例では、sizeof(SomeClass) は、Foo で作成される新しい typedef 型ではなく、typedef である元のクラスであることに注意してください。typedef で前方宣言を行うと、typedef であるクラスで何かを行う能力が制限されることに驚いています。

フォローアップ: XCode コンパイラを使用してテストしたところ、私の sizeof の質問は Visual C++ 6.0 コンパイラの問題であると思います。XCodeコンパイラはおそらく正しいと思いますが、現時点では他に試すことはありません. したがって、これは参考になりましたが、私の状況では最良の回答が機能しないため、個人的には現在のタスクで運が悪いです.

Visual Studio 2005 (MSBuild) ビルドでプロジェクトのビルドに時間がかかる理由を知ることができるかどうかを知りたいと思っていました。

突然、一部のコンピューターではビルド時間が 7 分になり、他のコンピューターではそれより短い時間 (4 分など) になりました。

そのため、プロジェクトに加えられ、ビルド時間が長くなる原因となっている変更を特定する必要があると思います。

どうすればそれができるかについてのアイデアはありますか?

VisualStudioのソリューションに含まれる各プロジェクトのビルド時間を表示する方法があることを私は知っています。しかし、私が探しているのは、ビルドをクリックしてから完了するまでの、ソリューション全体のビルドにかかった合計時間です。

とにかくこれを行うことはありますか？VisualStudio2008を実行しています。

ウィキペディアの参照に適した出版済みの書籍によると:

インストールは実行時ですか、それともコンパイル時ですか?

「プログラムのインストールまたはコピーの後または最中に「実行時エラー」が検出された」 -- ウィキペディア

このような自動生成ファイルがあります...

このようにビルドすると、ビルド時間が膨大になります。スクリプトを使用してすべての関数をそれぞれのケースに自動的にインライン化すると、ビルド時間が半分に短縮されます。GCC 4.5.0によると、-ftime-reportを使用すると、ビルド時間の約50％が「変数トラッキング」に費やされています。これはどういう意味ですか？スイッチから関数を引き出すという優れたキャッシュ局所性を維持しながら、コンパイルを高速化するにはどうすればよいですか？

編集：興味深いことに、プロジェクト全体の次のプロファイリング情報（問題のファイルだけでなく、優れたメトリックです。問題のファイルに最も時間がかかる）に従って、ビルド時間はデバッグビルドでのみ爆発しました。構築する）：

• デバッグ：8分50秒
• リリース：4分25秒

興味がある場合は、コンテキストが削除されたdo_funcのサンプルをいくつか示します。ご覧のとおり、問題の定義を少し簡略化して、関連する部分のみを表示しています。ご参考までに、すべてのself-> func呼び出しは、boost::signalの呼び出しです。

VS2010 Premium がインストールされた Win7 ボックスを入手しました。デスクトップ アプリのビルドは問題なく機能します。しかし、15 個の SL4 プロジェクトと 21 個のデスクトップ プロジェクトでこのソリューションを実現しました。SL 部分のビルドには時間がかかりすぎます。テストを実行するたびに、msbuild が何も変更されていないことを確認し、プロジェクトをスキップする必要があることを確認するのに約 3 秒かかるため、これは非常に苛立たしく、TDD を削除することをお勧めします。プロジェクトは非常に小さく、派手なものは何もありません。VS2008+SL3 から切り替える前は何の問題もありませんでした。一般的に VS2010 の速度が速いと不満を言う人がいると聞いたことがありますが、SL4 のビルド時間については何もありません。誰かが同じ問題を経験していますか?これに対する回避策はありますか?

最近、同じ仕様/ハードウェアを持つ 2 台の新しいビルド マシンを購入しました。私の理解では、同じまたは非常に類似したディスク イメージがそのマシンへのロードに使用されていました。しかし、Visual Studio 2008 は後で両方にインストールされたと思います。両方のマシンで同じソース コードのビルドを開始しましたが、一方のマシンは常に他方のマシンの約 40% の時間で終了します。マシンを監視して、他のプロセスが時間を浪費していないことを確認しましたが、何もありませんでした。

パフォーマンスの違いについて何か考えはありますか? 余分なオーバーヘッドを引き起こす特定の Visual Studio 設定がある可能性はありますか? それとも、システム設定に最も似ていますか？

私の現在のプロジェクトでは、テキスト ファイルから読み込まれた 10514 の Song 要素の入力配列を使用して、Java で TreeSet と TreeMap を使用しています。各曲には、アーティスト、タイトル、および歌詞のフィールドが含まれています。このプロジェクトの目的は、セットとマップを使用して歌詞を高速に検索することです。

まず、入力 Song 配列を繰り返し処理し、歌詞フィールドにアクセスして、次のコードを使用して歌詞の単語を繰り返し処理する Scanner オブジェクトを作成し commonWordsますlyricWords。

songSet を構築するために、次のコードを使用します。

ここで、buildSongSet はループ内から呼び出されるため、マップの作成は N^2 時間で実行されます。入力配列が 4 曲の場合、検索は非常に高速に実行されますが、10514 要素の配列全体を使用すると、6 GiB RAM を搭載した 2.4GHz マシンでマップを構築するのに 15 分以上かかる場合があります。このコードをより効率的にするにはどうすればよいですか? 残念ながら、入力データを減らすことはできません。