メモリ（リソース）の消費を抑えるには (ID:88852)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 > exeにコンパイルして実行してみましたが、 > リソース消費量は微々たる物でしたよ。 わー、やっぱり。 > 確かにその通りです。 > 残りの101個のフォーム内ではSpreadとかActiveToolBarなどたくさん使っています。 うわ、やっぱり？ えーと。 VBの拡張コントロールやサードパーティ製のコンポーネントは、標準コントロールとはまったく実装のされ方が異なります。 というか、コンポーネントごとにどんなふうに作られどう動作するのかは、ひとつずつ調べていかなければ本当のところはわかりません。 某帳票コントロールは、実際にはVB泊まった区無関係なところに独自の印刷エンジンを起動しておき、VBフォームに貼るコントロールはそのエンジンとの通信機能しか持たなかったりします。 ので、そのコントロールを貼ったフォームのインスタンスを2つ立ち上げて同時に印刷動作をさせると、1つのエンジンに2系統からの指示が混在し、ハングアップしたりしました。 上記の私のコメントで真っ先にSpreadを例に挙げたのは、私自身あまりにがメモリを食いすぎるので、私が担当したシステムで泣く泣く使用をあきらめたことのある思い出のあるコンポーネントだからです。多機能で使い出があるんですけどねぇ。 また、業務システムなど受注製造するシステムがSDIを採用することが多いのは、単機能のEXE(またはDLL)をメニューから呼ぶ構造にすることにより、瞬間メモリ消費量を最小に抑える(またはメモリ消費をなるべく意識せずに済ませる)というのが大きな理由のひとつです。 MDIのシステムにも参加したことがありますが、やはりメモリ消費が激しく、NT系(2000/XP)限定との条件が付いていました。(95系は動作未保証…つか現実動作しませんでした。) 残リソース量も、今回のシステムのような「VB以外」(拡張コントロールやコンポーネントは「VBではありません」)の部分の立ち居振る舞いを全部洗い出さない限り、その原因を突きとめることはできないように思います。 --- 申し訳ありませんが、今回のNTさんのシステムは、なるべくしてなったリソース不足のような気がします。 デッドコードやデッドフォーム(？)を整理する程度では解決できる問題でもなさそうです。 今のままで動作環境をNT系に限るか、MDIをあきらめて単機能SDI EXEの集合にするか、拡張コンポーネントをいくつか間引くか。 この場合の「間引く」は「Spreadを使用するフォームを減らす」のではなく、「このシステムではSpreadを使わない」などという意味でです。 いずれにせよ、苦渋の選択になりそうですね…