お世話になります。
プログラムをしたいのですが、いかんせん、Visual C++ 2010 Express でコンパイル、ビルドが遅くてイライラします。
メモリも2G積んでいてて、十分にメモリがあると思うのです。
ビルドのたびにハードディスクにアクセスして、ハードディスクがゴリゴリ言っているのがわかります。
これを、なんらかの手段で、メモリにヒットする確率を高める方法なんていうのはないのでしょうか?
ソース記述 → ビルド → 実行 までに30秒はかかってしまいます。
環境:
Windows7 HomeEdition
使用しているライブラリ Dxライブラリ
主な使用言語 C/C++
コンパイラ Visual C++ 2010 Express
Visal C++ 2010 Express を軽くする
Re: Visal C++ 2010 Express を軽くする
ビルドはソースファイルを読み込んでコンパイルし、オブジェクトファイルや実行可能ファイルを書き出す作業なので、dic さんが書きました:ビルドのたびにハードディスクにアクセスして、ハードディスクがゴリゴリ言っているのがわかります。
これを、なんらかの手段で、メモリにヒットする確率を高める方法なんていうのはないのでしょうか?
プロジェクトがハードディスク上にあるならハードディスクにアクセスするのは当たり前に感じます。
RAMディスクを使用してみてはいかがですか?
[search=google]RAMディスク[/search]
複雑な問題?マシンの性能を上げてOpenMPで殴ればいい!(死亡フラグ)
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 15年前
- 住所: 東海地方
- 連絡を取る:
Re: Visal C++ 2010 Express を軽くする
そこまで遅いことは無いはずですが、CPUとか他に問題はないでしょうか。
Eclipseなどが軽くて、VisualC++だけ異常に重いなど「Visual C++ 2010 Express」が原因であると断定した理由があったら教えて下さい。
あとVisual C++ 2008 Expressの方が軽いです。
あるいはMinGWなどもっと軽いものに移られるの手です。
Eclipseなどが軽くて、VisualC++だけ異常に重いなど「Visual C++ 2010 Express」が原因であると断定した理由があったら教えて下さい。
あとVisual C++ 2008 Expressの方が軽いです。
あるいはMinGWなどもっと軽いものに移られるの手です。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: Visal C++ 2010 Express を軽くする
>>みけCATさん
HDDにアクセスして当然といわれてしかたないです。
ただ、コンパイラやOSが、よくアクセスするファイルをメモリに格納させて
HDDにアクセスするのではなくて、メモリにアクセスさせてコンパイルを速くできないのか
と思ってました。
これは、ユーザーではなく、OSの仕事なので、なにかしらツールでもないのかなぁって思ってました。
>>RAMディスク
はい。HDDだとゴリゴリいっているので、速度の速いSSDに変えようかと思っていました。
しかし、このようなツールがあるんですね。知りませんでした。
いろいろフリーででてきましたけど、評判のいいのを入れました。
ありがとうございました。
>>softya(ソフト屋)さん
Visual C++ 2010 Express が原因と断定した理由ですが、
一番はやはり、コンパイルの時間ですね。
Eclipse は使ってなくて、JPad を使ってますが、やはり、コンパイル時に大量のファイルにアクセスするので
コンパイル時間が原因と思いました。
C/C++ のコンパイルと、Dxライブラリのコンパイルと、自前のソースのコンパイル、そしてリンク、exeの出力
にくらべて、javaは
パッケージ自体(ファイル数)が少なく、コンパイル時間がとても短くて済みます。
試しに、みけCATさんのおっしゃったRAMディスクを使用して、コンパイルしてみました。
① ソースコードをすべてHDDにおいてコンパイルした場合
ビルド 7秒
初回起動 4秒
変更なし2回目起動 3秒
② システムファイルを除くソースコードをRAMディスクにおいて、コンパイルした場合
ビルド 4秒
初回起動 4秒
変更なし2回目起動 3秒
となり、たしかにファイルにアクセスするところのパフォーマンスが向上しました。
補足:この計測のときには、CPUの優先順位を自動で変更してくれるフリーツール「オートギア」「http://www.vector.co.jp/soft/dl/win95/u ... 93319.html」を使用しています。
アクティブ時、非アクティブ時ともにCPU優先順位は通常以上
やはり、計測の結果、ファイルにアクセスするときが一番時間を消費しているように見えます。
ウィンドウがでるまでは、Dxライブラリの初期化で時間を消費していると思います。
(これ以上、高速化できないため)
いちおう、解決押しておきます。
HDDにアクセスして当然といわれてしかたないです。
ただ、コンパイラやOSが、よくアクセスするファイルをメモリに格納させて
HDDにアクセスするのではなくて、メモリにアクセスさせてコンパイルを速くできないのか
と思ってました。
これは、ユーザーではなく、OSの仕事なので、なにかしらツールでもないのかなぁって思ってました。
>>RAMディスク
はい。HDDだとゴリゴリいっているので、速度の速いSSDに変えようかと思っていました。
しかし、このようなツールがあるんですね。知りませんでした。
いろいろフリーででてきましたけど、評判のいいのを入れました。
ありがとうございました。
>>softya(ソフト屋)さん
Visual C++ 2010 Express が原因と断定した理由ですが、
一番はやはり、コンパイルの時間ですね。
Eclipse は使ってなくて、JPad を使ってますが、やはり、コンパイル時に大量のファイルにアクセスするので
コンパイル時間が原因と思いました。
C/C++ のコンパイルと、Dxライブラリのコンパイルと、自前のソースのコンパイル、そしてリンク、exeの出力
にくらべて、javaは
パッケージ自体(ファイル数)が少なく、コンパイル時間がとても短くて済みます。
試しに、みけCATさんのおっしゃったRAMディスクを使用して、コンパイルしてみました。
① ソースコードをすべてHDDにおいてコンパイルした場合
ビルド 7秒
初回起動 4秒
変更なし2回目起動 3秒
② システムファイルを除くソースコードをRAMディスクにおいて、コンパイルした場合
ビルド 4秒
初回起動 4秒
変更なし2回目起動 3秒
となり、たしかにファイルにアクセスするところのパフォーマンスが向上しました。
補足:この計測のときには、CPUの優先順位を自動で変更してくれるフリーツール「オートギア」「http://www.vector.co.jp/soft/dl/win95/u ... 93319.html」を使用しています。
アクティブ時、非アクティブ時ともにCPU優先順位は通常以上
やはり、計測の結果、ファイルにアクセスするときが一番時間を消費しているように見えます。
ウィンドウがでるまでは、Dxライブラリの初期化で時間を消費していると思います。
(これ以上、高速化できないため)
いちおう、解決押しておきます。