前の記事で、 Fatty Speed Factor Programsは、プログラムが「スローダウン」する理由についての概要をスケッチしました。
メモリファクターは重要であると強調されましたが、フレームワークによってはその「脂肪含有量」をテストする方法についてのアイデアがありませんでした。 それで、休日に落ち着いた正しい状態を受け入れて、私はそのような考えを生み出しました。
プログラムのロード時間と関連するコスト（ディスクI / Oおよびメモリ消費）を測定できるユーティリティが作成されました。 記事の最後にリンクします。
猫の下でのいくつかのテスト。
表にある3つの類似したプログラム-異なる言語でそれぞれ作成され、異なるフレームワークを使用するミニIDEを取り上げましょう。
| プログラム | 言語 | 枠組み | リンク |
|---|---|---|---|
| Drjava | Java8 | Swing + JGoodies | http://www.drjava.org |
| メモ帳++ | C ++ | WinAPI + Scintilla | https://notepad-plus-plus.org |
| シャープ開発 | C＃ | .NET 4.5 | http://www.icsharpcode.net/OpenSource/SD/Default.aspx |
各プログラムは、仮想システムの起動後にテストされます-最初の起動と繰り返し起動の時間を測定します。 仮想マシンの構成は、純粋なWindows 7、1Gbのメモリ（OSのニーズに応じて340Mbが使用されます）、2コアです。 ホスト-i5 3.2GHz、8Gbのメモリ。
テスト1-ウィンドウが開き、メッセージキューが開始されるまでの時間
開始時間を確認します。 開始後、stimeユーティリティはメモリとディスクの入出力（ページエラー）の統計を3秒ごとに表示します。これにより、フレームワークモジュールの動的な読み込みを監視できます。
stime.exe "C：\ Program Files \ Notepad ++ \ notepad ++。exe"
DiskIO：15.922MB WorkingSetSize：13.613MB PagefileUsage：7.5117MB
開始時間は1333.03ミリ秒、再起動：196.751ミリ秒
stime javaw -jar D：\ダウンロード\ drjava-beta-20160913-225446.jar
DiskIO：96.953MB WorkingSetSize：72.559MB PagefileUsage：82.148MB
DiskIO：103.76MB WorkingSetSize：73.621MB PagefileUsage：91.965MB
開始時間は5963.89ミリ秒、再起動：4541.6ミリ秒
stime.exe -splash "C：\ Program Files \ SharpDevelop \ 5.1 \ bin \ SharpDevelop.exe"
DiskIO：85.934MB WorkingSetSize：54.414MB PagefileUsage：45.117MB
DiskIO：136.74MB WorkingSetSize：71.609MB PagefileUsage：66.969MB
DiskIO：137.43MB WorkingSetSize：72.09MB PagefileUsage：67.035MB
開始時間は7863.89ミリ秒、再起動：1405.49ミリ秒
開始時間にわずかな不正確さが認められました-時間はメッセージキューの処理の開始を制御する機能によって検出されます-しかし、DrJavaなどの一部のプログラムはバックグラウンドで処理を開始しますが、ダウンロードにはまだ非常に長い時間がかかります。
したがって、回避策はJavaに使用されます-さらに、空ではないタイトルを持つ可視ウィンドウの外観を期待します。
同様に、SharpDevelopの場合、メインウィンドウが作成されるのを待機し、特別なオプションによってスプラッシュ抑制が有効になります。 そして、メインウィンドウが表示された後でも、SharpDevelopはまだ正常にロードされていました-起動後のDiskIO 3cに見られるように。
別の興味深い点-仮想マシンがシングルプロセッサとして構成された場合-Javaの読み込み時間が3倍（〜35c）増加しました。C++および.NETプログラムでは、これは影響しませんでした。
テスト2-ソースコードファイルのダウンロード時間と終了コマンドの実行
-quitオプションを指定して起動すると、stimeユーティリティは、子プロセスの開始直後にWM_QUIT closeコマンドを送信します。 メモリからプロセスをアンロードするセリフであるフルランタイムを確認します。
stime.exe -quit "C：\ Program Files \ Notepad ++ \ notepad ++。exe" stime.cpp
DiskIO：16.734MB WorkingSetSize：14.32MB PagefileUsage：8.0664MB
フルランタイムは1611.67ミリ秒、再起動：240.524ミリ秒
stime.exe -quit javaw -jar drjava-beta-20160913-225446.jar JsonIterator.java
DiskIO：97.992MB WorkingSetSize：75.52MB PagefileUsage：100.41MB
完全な実行時間は6860.405ミリ秒、再起動：4533.613ミリ秒
stime.exe -splash -quit "C：\ Program Files \ SharpDevelop \ 5.1 \ bin \ SharpDevelop.exe" kernel.cs
DiskIO：127.4MB WorkingSetSize：68.148MB PagefileUsage：53.133MB
完全な実行時間は9752.181ミリ秒、再起動：3066.784ミリ秒
ここでも、Javaの回避策を適用する必要があります-アプリケーションウィンドウが閉じた後、javaw.exeを撮影します
結論-フレームワークのロードは、大量のランダムI / Oを要するため、非常に高価な操作です。 高速プログラムが必要な場合は、コンパクトにします。
さて、詳細な診断のために、Russinovichのより詳細なユーティリティとプロファイリングツールを忘れてしまいます。