トップ回答者
デバッグビルドとリリースビルド:各出力の処理速度に差がない …

質問
-
初心者なので、リリースビルドをして実行させるのは初めてです。
デバッグビルドよりリリースビルドの出力の方がかなり処理が速くなると期待していたのですが、
目で見る限り処理速度に差が無いようです。
具体的には、PictureBoxを移動してから写真を入れ替えるという処理を行ってているのですが、
「PictureBoxの場所が変わり、それから写真が入れ替わる」のが、リリースビルドでも目で確認
できます。時間的には0.1秒程度でしょうか。(正確には計測できません)
Basicなので処理速度はこれぐらいで、デバッグビルドとリリースビルドの各出力に処理速度の
違いはほとんど無いというのが現実でしょうか?
回答
-
「PictureBoxの場所が変わり、それから写真が入れ替わる」のが、リリースビルドでも目で確認
このような処理(画面への描画等)は、デバッグやリリースを切り替えることで差は出ないと思います。
できます。時間的には0.1秒程度でしょうか。(正確には計測できません)
Basicなので処理速度はこれぐらいで、デバッグビルドとリリースビルドの各出力に処理速度の
画面への描画を省くのが良さそうですが、PictureBoxの場所を移動する前にVisible = falseにして、移動・写真入れ替え完了でVisible = trueにすると、その途上が見えなくなるかもしれません。
# 実際にはあんまり変わらないかも?
デバッグやリリースで影響が出てくるポイントは具体的に言い表しづらいのですが、変数の代入とかループ処理とか計算処理とかといった類と大雑把に捉えておくと良いかもしれません。
解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。- 回答としてマーク yukaaki 2009年6月11日 2:56
-
デバッグやリリースで影響が出てくるポイントは具体的に言い表しづらいのですが、変数の代入とかループ処理とか計算処理とかといった類と大雑把に捉えておくと良いかもしれません。
CやC++(C++/CLIを除く)ではネイティブコードを生成しています。デバッグビルドではデバッガが介入しやすいような形式にネイティブコードのレイアウトが整えられ、その分、速度が落ちます。
対してC#、C++/CLI、VB.NETなどの.NETではネイティブコードを生成しているのではなくILを生成し、それを実行時にネイティブコードに変換しながら動作しています。
デバッグビルドでILが多少変わりますが、ほとんど速度に影響ありません。ILからネイティブコードに変換する際、デバッガが介入するかしないかでネイティブコードが変わってきます。
うまく言葉で表せきれていませんが、デバッガ自体が動作していない限り、デバッグビルドでもリリースビルドでも大差ないと考えています。- 回答としてマーク yukaaki 2009年6月11日 2:56
-
デバッグビルドでILが多少変わりますが、ほとんど速度に影響ありません。ILからネイティブコードに変換する際、デバッガが介入するかしないかでネイティブコードが変わってきます。
確かに、適当な物言いで申し訳ありません。
ついでと言っては難ですが、JITが抑制されるのは、オプション設定のデバッグ - 全般にある項目でJIT最適化を抑制するという設定が有効な状態でVisual Studioからデバッグ実行/プロセスにアタッチ等をした場合になります。
Release構成のデフォルトの設定であれば、ConditionalAttribute("DEBUG")とついているメソッドの呼び出しが削除されるといった効果はあります。
(Debug.WriteLine等の呼び出しがコンパイル時に削除される)
これは、DEBUG定数の定義がDebug構成だとデフォルトでOFFであることが作用します。
# 「コードの最適化」がどの程度作用するかは、ちょっと情報に巡り会えていない。orz
解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。- 回答としてマーク yukaaki 2009年6月11日 2:56
すべての返信
-
「PictureBoxの場所が変わり、それから写真が入れ替わる」のが、リリースビルドでも目で確認
このような処理(画面への描画等)は、デバッグやリリースを切り替えることで差は出ないと思います。
できます。時間的には0.1秒程度でしょうか。(正確には計測できません)
Basicなので処理速度はこれぐらいで、デバッグビルドとリリースビルドの各出力に処理速度の
画面への描画を省くのが良さそうですが、PictureBoxの場所を移動する前にVisible = falseにして、移動・写真入れ替え完了でVisible = trueにすると、その途上が見えなくなるかもしれません。
# 実際にはあんまり変わらないかも?
デバッグやリリースで影響が出てくるポイントは具体的に言い表しづらいのですが、変数の代入とかループ処理とか計算処理とかといった類と大雑把に捉えておくと良いかもしれません。
解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。- 回答としてマーク yukaaki 2009年6月11日 2:56
-
デバッグやリリースで影響が出てくるポイントは具体的に言い表しづらいのですが、変数の代入とかループ処理とか計算処理とかといった類と大雑把に捉えておくと良いかもしれません。
CやC++(C++/CLIを除く)ではネイティブコードを生成しています。デバッグビルドではデバッガが介入しやすいような形式にネイティブコードのレイアウトが整えられ、その分、速度が落ちます。
対してC#、C++/CLI、VB.NETなどの.NETではネイティブコードを生成しているのではなくILを生成し、それを実行時にネイティブコードに変換しながら動作しています。
デバッグビルドでILが多少変わりますが、ほとんど速度に影響ありません。ILからネイティブコードに変換する際、デバッガが介入するかしないかでネイティブコードが変わってきます。
うまく言葉で表せきれていませんが、デバッガ自体が動作していない限り、デバッグビルドでもリリースビルドでも大差ないと考えています。- 回答としてマーク yukaaki 2009年6月11日 2:56
-
デバッグビルドでILが多少変わりますが、ほとんど速度に影響ありません。ILからネイティブコードに変換する際、デバッガが介入するかしないかでネイティブコードが変わってきます。
確かに、適当な物言いで申し訳ありません。
ついでと言っては難ですが、JITが抑制されるのは、オプション設定のデバッグ - 全般にある項目でJIT最適化を抑制するという設定が有効な状態でVisual Studioからデバッグ実行/プロセスにアタッチ等をした場合になります。
Release構成のデフォルトの設定であれば、ConditionalAttribute("DEBUG")とついているメソッドの呼び出しが削除されるといった効果はあります。
(Debug.WriteLine等の呼び出しがコンパイル時に削除される)
これは、DEBUG定数の定義がDebug構成だとデフォルトでOFFであることが作用します。
# 「コードの最適化」がどの程度作用するかは、ちょっと情報に巡り会えていない。orz
解決した場合は、参考になった返信に「回答としてマーク」のボタンを利用して、回答に設定しましょう(複数に設定できます)。- 回答としてマーク yukaaki 2009年6月11日 2:56