自宅の PC でビルド時間を短縮する安価な方法を必死に探しています。Windows XP でファイルの Last Access Time 属性を無効にして、単純な読み取りでディスクに何も書き戻さないようにする方法についての記事を読みました。
それも本当に簡単です。DOS プロンプトで次のように書き込みます。
fsutil behavior set disablelastaccess 1
C++ プロジェクトの構築のコンテキストで試したことがある人はいますか? 欠点はありますか？
[編集] トピックの詳細はこちら.
「NTFSは、ファイルの最終アクセス時刻への更新を、最後のアクセスから最大1時間遅らせます。」
これをオフにする本当の意味はありません-元の記事は間違っており、データはすべてのアクセスで書き出されるわけではありません。
編集：
その記事の著者が10倍のスピードアップを主張した理由については、彼はスピードアップを間違ったことに帰したと思います。彼は8.3ファイル名の生成も無効にしました。ファイルの8.3ファイル名を生成するには、NTFSは基本的に各可能性を順番に生成し、それがすでに使用されているかどうかを確認する必要があります（参照なし。レイモンドがそれについて話していると確信していますが、リンクが見つかりません）。すべてのファイルが同じ最初の6文字を共有している場合、この問題に悩まされることになります。当然のことながら、ファイルを区別する文字を最初の6文字に配置して、衝突しないようにする必要があります。短い名前の生成をオフにすると、これを防ぐことができます。
試してみて、違いがあるかどうかを確認することをお勧めします。
ただし、これが実際に違いを生むことについては悲観的です。大規模な/クリーンなビルドでは、とにかく大量のデータを書き出すため、ファイルアクセス時間の調整にはそれほど時間がかかりません (さらに、おそらくとにかくキャッシュされます）。
私は間違っていることが証明されたいと思っています。
結果：
最終アクセス時刻を有効または無効にして、デバッグ構成とリリース構成の両方で、作業中のコード ベースでいくつかのビルドを実行しました。
私たちのソース コードは約 39 MB (ディスク上のサイズは 48 MB) で、これらのテスト用に構築した構成用にその約半分を構築します。デバッグ ビルドでは1.76 GBの一時ファイルと出力ファイルが生成されましたが、リリースではそのようなデータが約 600 MB 生成されました。Ant と Visual Studio コマンド ライン ビルド ツールの組み合わせを使用して、コマンド ラインでビルドします。
私のマシンは Core 2 Duo 3GHz で、4GB の RAM、7200rpm の HDD、Windows XP 32 ビットを実行しています。
最終アクセス時刻を無効にしたビルド:
デバッグ時間 = 6:17、5:41
リリース時間 = 6:07、6:06
最終アクセス時刻を有効にしてビルドする:
デバッグ時間 = 6:00、5:47
リリース時間 = 6:19、5:48
どちらの場合も、ファイルはすでにシステム キャッシュにある可能性が高いため、メモリから読み取るだけでよいため、全体として 2 つのモードの違いに気付きませんでした。
適切なプリコンパイル済みヘッダー (Visual Studio がプロジェクトで作成する自動生成ヘッダーではない) を実装するだけで、費用対効果が最大になると思います。これを数年前に職場で実装したとき (コード ベースがはるかに小さかったとき)、ビルド時間が以前の 3 分の 1 に短縮されました。
Windowsボックスではこれを試していませんが（今夜は感謝します）、Linuxでも同様のこと（ドライブをマウントするときのnoatimeオプション）により、かなり高速化されました。
最終アクセス時刻が監査目的以外に役立つ用途は考えられません。それでも、Windows はそれにアクセスしたユーザーを保存しますか? 私は Linux がそうでないことを知っています。
これは良い代替手段ですが、一部のツールに影響します。Remote Storage Service や、ファイル アクセス統計に依存してファイル システムを最適化するその他のユーティリティ (Norton Defrag など) と同様です。
「最終アクセス時間」の質問から注意をそらしたくはありませんが、ビルドを高速化する方法は他にもあるかもしれません。コンテキストとプロジェクトのセットアップがわからないため、何が遅いのかを判断するのは困難ですが、役立つ可能性があることがいくつかあります。
「uber」ビルドを作成します。つまり、次のような一連の行を含む単一のコンパイル uber.cpp ファイルを作成します。
#include "file1.cpp"
#include "file2.cpp"
競合する静的変数名で問題が発生する場合がありますが、一般的には簡単に解決できます。初期設定は面倒ですが、ビルド時間は劇的に長くなる可能性があります。私たちにとって最大の欠点は、開発者スタジオでは、そのファイルが uber ビルドの一部である場合、ファイルを右クリックして「コンパイル」と言うことができないことです。それは大したことではありません。Uber ファイルをコンパイルするが、ビルド プロセスから個々の cpp ファイルを除外する「uber」ビルド用の個別のビルド構成があります。さらに情報が必要な場合は、コメントを残してください。それを入手できます。また、オプティマイザーは、uber ビルドでわずかに優れた仕事をする傾向があります。
また、インクルード ファイルの数が多い、またはインクルード ファイル間の依存関係が多いですか? その場合、ビルド時間が大幅に遅くなります。
プリコンパイル済みヘッダーを使用していますか? そうでない場合は、解決策としてそれを検討することもできます。
ビルド時間の遅さは通常、大量のファイル I/O に起因します。すべてのファイルを開き、読み取り、解析するだけで、これがビルドの最大の時間の浪費です。ファイル I/O を削減すると、ビルド時間が改善されます。
とにかく、トピックを少し脱線させて申し訳ありませんが、ファイルの最終アクセス時刻の設定方法を変更するという当面の提案は、やや「大ハンマー」ソリューションのように見えました。
アクセス時間を無効にすると、ドライブへの書き込み回数が減るため、ssd (ソリッド ステート ドライブ - カード、USB ドライブなど) を使用する場合に便利です。すべてのソリッド ステート ストレージ デバイスには、個々のアドレスへの書き込み回数によって測定される寿命があります。一部のメディアでは、最低でも数十万、場合によっては 100 万と指定されています。オペレーティング システムやその他の実行可能ファイルは、1 回の操作で多くのファイルにアクセスできるだけでなく、ユーザー ドキュメントにアクセスすることもできます。これは、eee PC、組み込みシステムなどに適用されます。
パフォーマンスが少し向上します。それ以外には、それ以上のことはできません (もちろん、ファイルが最後にいつアクセスされたかを確認することはできません)。nLiteを使用して Windows XP をインストールすると、不要な肥大化を解消するために、デフォルトでオフになっています。
ビジー状態のサーバーの場合、通常、最終アクセス時刻を無効にすることをお勧めします。唯一の潜在的な欠点は、最終アクセス時刻を使用して、たとえばファイルが書き込まれていないことを伝えるスクリプトがある場合です。
とはいえ、C++ プロジェクトのビルド時間を改善したい場合は、 Recursive Make Considered Harmful を読むことを強くお勧めします。この記事は約 10 年前のものですが、ビルド スクリプトの再帰的定義がビルド時間をどのように長くするかについて指摘していることは、今でも十分に理解する価値があります。
To Mike Dimmick:
Try to connect USB drive with many files and copy them to your internal drive. That's also the case in addition to program compilation (which is described in original post).