DOBON.NET DOBON.NETプログラミング掲示板過去ログ

フォームで InitializeComponent までの時間

環境/言語:[Windows8 VS2012 .Net Framework 4]
分類:[.NET]

いつも大変参考にさせて頂いております。

Windows8 + VS2012 + SQLServer にて開発したソフトを利用しています。

クライアントがWindows7の場合に1秒で開くフォームが
クライアントがWindows8の場合に30秒以上かかります。
データベースサーバーとのやり取りのあるフォームで発生します。


どこがボトルネックになっているのかを調べようと試みましたところ、
フォームのインスタンスを作成するコードを実行してから
.Designer.vb で定義される Private Sub InitializeComponent
関数の呼び出しまでに大半の時間が割かれていました。

タスクマネージャーでも、この間、メモリが見る見る食われて行き
CPUも相当忙しく動いています。


Windows 7 以下では発生せず、
Windows 8 で「デバッグ開始」にて実行したときにも発生せず、
ClickOnceアプリケーションとしてインストールをした
Windows 8 クライアントのみでこの事象が発生します。

一生懸命勉強しようと思っていますが、何を調べればよいのか、
手がかりが手に入ればと思い投稿しました。

よろしくお願いします。
> Windows 8 で「デバッグ開始」にて実行したときにも発生せず、

> ClickOnceアプリケーションとしてインストールをした
> Windows 8 クライアントのみでこの事象が発生します。

この2つの「Windows 8」は同じ端末ですか?

あと、InitializeComponent内で時間のかかりそうな処理は含まれていますか?
さっそくありがとうございます。

同じWindows 8 の端末です。同じWindows8で

「デバッグ開始」で実行 → 問題なし
ClickOnceのクライアントとして実行 → 時間がかかる

です。

InitializeComponent内で時間のかかりそうな処理はありません。
この関数の最初から最後までの処理時間を計測しましたが
1秒未満です。

その後、デバッグ→パフォーマンス分析の開始

を実行してみたところ、時間のかかるフォームのコンストラクタと思わしき
ctor という関数と、そこから呼び出される clr.dll が
時間のかかる主体だという結果が出ていますが、ここから先が分かりません。


引き続きよろしくお願いします。
添付ファイル: u2.gif (22 KB)
これは起動時に時間がかかるということでしょうか?
例えば、毎回起動に時間がかかるとか、初回のみ時間がかかるとかはどうでしょう。
あと、ClickOnceでの配布のようですが、例えば格納されているexeを直接実行した場合でも状況は変わらないでしょうか。

お役に立てなかったらゴメンナサイ。
■No31360に返信(フレアジャグラーさんの記事)
> 同じWindows 8 の端末です。同じWindows8で
>
> 「デバッグ開始」で実行 → 問題なし
> ClickOnceのクライアントとして実行 → 時間がかかる
>
> です。

ClickOnce の検証など、起動前の処理に時間がかかっていると予想されます。
なので、デバッグ環境でプロファイルをとるなど、マネージコードの部分でデバッグしても問題の解決につながらない可能性があります。

たとえば、通信状況を確認するツールであるとか、起動途上のプロセスをデバッガで止めてどの関数を実行中か調べる(シンボルをダウンロードして関数名を見える形にする前提)とか、そういった解析が必要な状況に見えます。
あるいは、OS のイベントログに何か残っていないかですかね。

// 具体的なアドバイスでなくてすみません。。。
皆様ありがとうございます。

「起動時」に時間がかかっているのではなく、
フォームの初回生成時に時間がかかっています。
起動はスムーズで、その後別のフォームを開こうと
すると、あらゆるフォームで
ctor(コンストラクタ)と、そこから呼び出される clr.dllに
時間がかかります。

なお、同じフォームを同一アプリケーション内で2回目に開くと
比較的スムーズです。

Windows7/Vista クライアントでは再現せず、
Windows8でデバッグの開始にて実行しても再現しません。

引き続きよろしくお願いします。
皆様、いろいろとありがとうございます。

My Project コンパイルの設定にて

対象のCPUを Any CPU ではなく x86 に限定することで
当該現象の発生を抑制することができました。

調べると、64bit版のclr.dll もしくは .NET FrameWork 4.5の仕様(バグ)
に関連しているような気もしています。ただし、私の理解の範囲を
超えるのと、64bitアプリケーションに固執はしていないので、
これにていったん解決としたいと思います。ありがとうございました。
解決済み!

DOBON.NET | プログラミング道 | プログラミング掲示板