- ベストアンサー
リリースビルドで遅くなる
- リリースビルド時の速度がデバッグビルドよりも遅くなる問題が発生しています。特にメモリマップドファイルの処理に関連している可能性があります。
- デバッグビルドではキャッシュの効果により、同じ処理を繰り返しても処理時間が短縮されますが、リリースビルドでは繰り返しても処理時間が変わりません。
- この問題はキャッシュの方式に関連している可能性があります。Windows APIなどを使用してキャッシュの処理を改善することで解決できる可能性があります。
- LongSecret
- お礼率96% (146/151)
- C・C++・C#
- 回答数3
- ありがとう数3
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
VCのVerがわかりませんが、昔経験があります。 確かリンカのオプションでサイズ重視、速度重視とかの設定を変えると速くなりました。 ポインタをたくさん使う場合は速度重視の方が速かった気がします。 ほかにもマニフェストの組み込みとかいろいろ設定があるのでいじってみてください。 デフォルトだとコマンドラインからコンパイルした方がサイズが小さく高速です。 cl でコンパイルリンクします。
その他の回答 (2)
- 5S6
- ベストアンサー率29% (675/2291)
スタートメニューにVisual Studio コマンド プロンプトってありますよね。 cl /? とやれば最適化のオプションがたくさんでてきます。 プログラムの性質により最適化が異なるのでいろいろやってみましょう。 SSE3を使う設定や64bitコンパイルすれば更に速くなりますよ。 /arch:SSE3 など 他にはソースの変更が必要ですがマルチスレッドにすれば速くなります。 それとメモリを多く積んでいる場合に限りますが・・・ Windows7で8GB,16GBなどの場合、スワップファイル(仮想メモリ)を使用しない。 設定にすれば、なんじゃこりゃ！？と思うほど速くなります。 fpsなどのゲームで体験すると数倍起動が速くなりますし。 ちなみに昔C++のプロジェクトで４０分かかる計算を１０秒台まで最適化したことあります。 簡単なことで意外と速くなりますよ。
お礼
どうもどうも ＞他にはソースの変更が必要ですがマルチスレッドにすれば速くなります。 これに関しては、既に必要な個所でマルチスレッドにしてあります。無駄なスレッドは作っていませんが、通常で7個、最大で同時に10個ほどのスレッドが動きます。 ※音声マルチバッファやそれにまつわるタイマースレッド、フィルタ演算、ファイル出力、独自ファイル形式のバイナリの順序を入れ替えた場合などの、既に作った数百ファイルの自動更新、あるいは解析処理などなど 別の作業やりながら可、ということになるので、起動してから確実に1回は行う必要がある処理が7秒程度で片付ければ、現状でも十分です。（それ以降は数千分の以下とか、大抵のアクションに対しては少ない演算で書き換えて行けるので） ＞ちなみに昔C++のプロジェクトで４０分かかる計算を１０秒台まで最適化したことあります。 私はまだまだプログラミングを始めて1年ぐらいだったころなら、何時間かかかった処理を（正確さを多少犠牲にして）5秒程度に出来たこともありましたが このごろだと CPUのクロック数と最小演算量を考えて、おそらく同じハードでは、コードの整合性を保つ限り、さすがにそれほど飛躍的に縮むのは物理的に不可能に思います。 ただし ＞cl /? ＞とやれば最適化のオプションがたくさんでてきます。 なるほど そして出てきたコマンドは プロパティ→構成プロパティ→C/C++→コマンドライン→追加のオプション に半角スペース区切りで書きこむことで… っていうことですね？ 残念ながらこちらの環境では /arch:SSE3 が使えず、また色々と試してみましたが、今のところコンパイルオプションの変更による、これより大きな改善はみられていません。 （浮動小数をfastにすると0.2秒くらいは縮んだかな？という感じですが、さすがにここはPreciseにしておきたいですし） 64bitコンパイルの実験は、32bitなので出来ず 同じ理由で ＞Windows7で8GB,16GBなどの場合、スワップファイル(仮想メモリ)を使用しない。 ＞設定にすれば、なんじゃこりゃ！？と思うほど速くなります。 も試すことができません。 ただ、そのうちWindows7 64bitは手に入れたいので それが叶ったら是非試してみようと思います。 なお、それ以外の構想としては CUDA対応のビデオカードを使い けた外れに多い演算は（画像処理だけじゃなく音声処理の場合だろうが）CUDAからビデオメモリに委託 という手も考えています。 そもそもCPUではなくGPUでドカーンとやってもらおうという作戦です。 （ただし最速パターンだと浮動小数の演算結果が異なるらしいので、その辺は試してみないと） うまくいった場合、CUDAを使うバージョンと 対応できない環境でも使えるようにする、非CUDAバージョンの実行ファイルを両方リリースする（か、それによるパフォーマンスの低下が気にならないレベルなら動的リンクをするかする）可能性が高いですが 聞いた話から判断すると 少なくともこの方法だと うまくいけばCUDA対応版の、その重要な部分は数倍程度速くなる、かもしれません。 まぁそんなこんなですが、とりあえず ありがとうございました♪
- anpauro11
- ベストアンサー率28% (4/14)
メモリのキャッシュの使い方じゃないでしょうか？ 私が知ってる範囲では、 デバッグビルドではアロケータがメモリに割り当て済みの領域を感知して上書きするのですが、 リソースビルドでは上書きすることなく、新規で領域を割り当てる するとメモリ使用量が上がるので動作が遅くなる・・・ということ？（自信なし） 対策としてはnewで作成したオブジェクトをdeleteでつぶさに削除することに尽きると思います。 上記を一度試してみてください。
お礼
ありがとうございます♪ ＞デバッグビルドではアロケータがメモリに割り当て済みの領域を感知して上書きするのですが、 ＞リソースビルドでは上書きすることなく、新規で領域を割り当てる おや、そうなのですか！？ どっちにしても「コード通りの挙動はする」という意味での「バグにはならないような挙動をする」ということですよね？ 現状バリバリの完全ネイティブですので ガベージコレクタは動いてないので ＞対策としてはnewで作成したオブジェクトをdeleteでつぶさに削除することに尽きると思います。 これはかなり正確に（使いまわした方が得策かどうかも考慮に入れたうえで、この場合はこの時点まででdeleteしていいな、こっちはとっといた方が良い、とかも踏まえて）行うことを心がけています。 なお このアプリケーションの機能上 もしも馬鹿正直にメモリを使うと 何百MBとか1GB越えとか平気で行ってしまう という感じになってきてますが 音声や描画のマルチバッファ（多すぎない範囲でビデオメモリも使用）に加え、場合により自作のメモリプールや メモリマップドファイルの有効活用により よほどのことをしない限り どんなにガンガンに使っても 「最大限の計算をしているところ」でも、まずメモリ使用量は（仮想メモリ込みで）100MB以内程度、メモリのみでは20MB以内程度には大抵収まる 通常時ではメモリ使用が8MB以内、仮想メモリ込みでも15MB程度以内にはまず収まっています。 メモリ使用量の推移からみても、リークは確認できた範囲では全て潰していると思われます。 そして音声のマルチバッファ＋描画位置を30FPS程度で2か所のウインドウに書き換えしつつ 同じく30FPSで「再生地点を示すライン、及びその背景部分に当たるところ」の再描画 を、DirectXなどのAPIを、こっちのアプリでは今のところ使わずに WindowsAPIのGDIのみで行って タスクマネージャにCPU使用率が0%と表示されてる、というような状態です。 もっと「ここを改良したい」と思うところを改良できる方法を思いついたら、その都度改良しますが かなりの研究と手間をかけたので （そのために、車輪の再発明の必要が生じたりして、開発速度はところどころ遅くなってしまっていましたがｗ） 現状でも「パフォーマンスに関してはなんでもござれ」というような状態になっていました。 そう、今回の謎が出るまでは（苦笑） しかし、下記の通りの状態となりました。 とてもよかったです。
お礼
ありがとうございます♪ （バージョンは色々あってまだ2008EEです） リリースサイドも３度は確認したので デバッグ同様速度重視に合わさってた気がしたのですが 気になったのでサイズ重視に変更してみました。 すると！！ 797KB(デバッグ側速度重視） ↓ 690KB(リリース側これまで） ↓ 431KB にまでなりました。 すごいですねこれ すると！ 2度目以降9秒弱程度で出来るようになりました！ そこで今度は「最大限の最適化」に すると 616KBに。 そしてなんと 7秒弱程度で出来てしまいました！ しかし、なぜでは「速度重視」でダメなのか… と思い、再度「速度重視」に設定すると・・・ 606KBに！！ あれ？ あれええ！？ そしてこれも 7秒弱程度で出来てしまいました！ 確かに確認したのですが 今改めてそこんとこいじってどこに設定してみても 「細い文字」に戻りません。 もちろん「無効」に戻しても太字のままです。 ただし、無効にしたら 690KBと、同じ実行ファイルサイズになりました。 という事は、単に見間違いだったか あるいは、それよりは低い確率で、もしかしたら 何らかの理由により「細字になっていた」ために 誤作動していた（？） のかもしれません。 いずれにしても、一応解決という事になってしまいましたが VC++の仕様は知っておきたいので ＞デフォルトだとコマンドラインからコンパイルした方がサイズが小さく高速です。 ＞cl でコンパイルリンクします。 この部分は、具体的にはどういう手順を踏めばいいのでしょうか？