- ベストアンサー
VC++とアプリケーション上の実行の違い
- VC＋＋で作ったプログラムをデバッガ上で起動した場合と、ビルドにより出来た実行ファイルを直接起動した場合とでは、違いがあるのでしょうか？
- デバッガ上でプログラム中止時にアクセス違反の例外が出るが、アプリケーションから直接起動した場合は処理が遅くなるだけで警告は出ない。
- アプリケーションをVCを通さず実行するとPC自体の設定に影響を与える可能性があり、処理速度が低下している可能性もある。映像出力用のメモリが割り当てられなくなった可能性もある。
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
取り込み時におけるボトルネックは、 ・外部端末から内部端末まで ・内部処理による転送ロス が挙げられます。 前者の場合、ＣＰＵ過負荷率には依存しにくいと考えられる為 転送バス回路やＲＡＭ、グラフィックメモリなどハードウェア依存に 目を向けますが、質問者さんの場合、アプリケーションで操作した場合 遅くなると言う解釈であれば、 例えば、コンポーネント側にヒープアドレスを渡すとした場合 適切でないブロックであるため、コンポーネントが 非正規な動作になってしまう（遅くなる）かと思います。 共有メモリアドレスを渡せばいくかもしれません。
その他の回答 (2)
＞仮想メモリというのはページングファイルというやつでしょうか？ 訂正の意味を含めてこの場合、動的バッファですので プログラムデータではなくメディアデータですから、 ベージングのリプレースメントではなく直接、ディスクメモリを利用 できるはずです。 ＞イメージバッファのためのメモリ確保でしょうか？ 動画制御と言うことはコンポーネントを使用しているとして コンポーネント制御側が適切にストックバッファを 割り当てるかと思います。 ＞物理メモリが1.5ＧＢあってもメモリをＯＳが許可しないとコミット ＞チャージは２５５ＭＢくらいで止まってしまうのでしょうか？ 例えば、動画制御プログラムが割り当てるバッファにより 実質、コミットチャージオーバー（１．５ＧＢ超）の見込みがある際 動画バッファは大域的な1ブロックとなり、 他の優先プロセスも考慮して仮想空間に割り当てる策を とるかと思います。 主記憶上に巨大データ群がないため２５５ＭＢ程度になると 考えられます。 以前はコミットチャージがいっぱいだったのは、実行プロセスが 現在より少なく、ギリで収まっていたからだと思います
補足
ありがとうございます。 ＞動画制御と言うことはコンポーネントを使用しているとして ＞コンポーネント制御側が適切にストックバッファを ＞割り当てるかと思います。 という作業はハードの要因としては何の比重が高いのでしょうか？ 当方のプログラムはWEBカメラからの取り込みを制御するものなのですが、 ここの作業が遅く、対策を練りたい次第です。 判る限りでは ・メインメモリ ・インターフェイス（USB２．０など） ・メインCPU ・グラフィックカード ・その他
仮想メモリのアクセス違反ではないでしょうか？ 動画制御ですから当然、必要コミットが上昇してスワップ要求が 発生するのでディスクメモリへのアタッチが必要ですが そのメモリをＯＳが許可しないためコミットチャージが ２５５ＭＢ（足らずと言う見方です）になるかと思われます。 処理が遅くなるのは、アプリケーション自体の必要メモリでなく プログラムが動的に割り当てるヒープに関してはメインメモリ 内での小ブロックに割り当て＞開放＞割り当て・・・の繰り替えし によりオーバーヘッドがきつくなるからかと思います。 仮想メモリを動的に許可させて、ソフト終了時に禁止させる のはだめですか？
補足
仮想メモリというのはページングファイルというやつでしょうか？ それともイメージバッファのためのメモリ確保でしょうか？ 物理メモリが1.5ＧＢあってもメモリをＯＳが許可しないとコミットチャージは２５５ＭＢくらいで止まってしまうのでしょうか？ 質問ばかりですみません。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/images/related_qa/c205_3_thumbnail_img_sm.png)
お礼
共有メモリアドレスというのはまだ未知でした。 ソフトの面からも引き続き検討させていただきます。 ※やはりグラフィックメモリはあるにこしたことはないですね