В предыдущей статье Жирные программы-факторы скорости были набросаны наметки по теме — почему программы "тормозят".

Был выделен фактор памяти, как важный, но не было идей по его тестированию его “жирности” в зависимости от фреймворка. И вот, приняв на праздниках спокойное правильное состояние, я такую идею сгенерировал.

Была написана утилита, которая позволяет измерить время загрузки программы и связанные с этим расходы — дисковый ввод/вывод и потребляемую память. Ссылка в конце статьи.

Некоторые тесты под катом.

Возьмем три похожие программы — мини-IDE, написанные соответственно на разных языках и использующие разные фреймворки — в таблице

Каждая программа тестируется после загрузки виртуальной системы — замеряем время первого и повторного запусков. Конфигурация виртуальной машины — чистая Windows 7, 1Gb памяти (340Мб используется под нужды ОС), 2 ядра. Хост — i5 3.2GHz, 8Gb памяти.

Тест 1 — время до открытия окна и запуска очереди сообщений

Смотрим Starting Time. После запуска утилита stime каждые 3 секунды выводит статистику по памяти и дисковому вводу выводу (ошибки страниц), что позволяет мониторить динамическую подгрузку модулей фреймворка.

stime.exe "C:\Program Files\Notepad++\notepad++.exe"
DiskIO: 15.922MB WorkingSetSize: 13.613MB PagefileUsage: 7.5117MB
Starting time is 1333.03 ms, Повторный запуск: 196.751 ms

stime javaw -jar D:\Downloads\drjava-beta-20160913-225446.jar
DiskIO: 96.953MB WorkingSetSize: 72.559MB PagefileUsage: 82.148MB
DiskIO: 103.76MB WorkingSetSize: 73.621MB PagefileUsage: 91.965MB
Starting time is 5963.89 ms, Повторный запуск: 4541.6 ms

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
Starting time is 7863.89 ms, Повторный запуск: 1405.49 ms

Была замечена небольшая некорректность со временем старта — время засекается функцией, контролирующей начало обработки очереди сообщений — но некоторые программы, например DrJava, начинают ее обрабатывать в фоновом режиме, хотя загрузка еще продолжается очень долго.

Потому для Явы используется обходной путь — ожидаем дополнительно появления видимого окна с непустым заголовком.

Аналогично, для SharpDevelop ожидание создания главного окна и подавление сплеш включено специальной опцией. И даже после появления главного окна SharpDevelop еще прилично подгружался — что видно по DiskIO через 3с после старта.

Еще интересный момент — когда виртуальная машина была сконфигурирована однопроцессорной — время загрузки Явы вырастало втрое (~35c), для С++ и .NET программ это не влияло.

Тест 2 — время загрузки файла исходного кода и отработки команды выхода

При запуске с опцией -quit, утилита stime сразу после запуска дочернего процесса посылает команду закрытия WM_QUIT. Смотрим Full run time — засечку по выгрузке процесса из памяти.

stime.exe -quit "C:\Program Files\Notepad++\notepad++.exe" stime.cpp
DiskIO: 16.734MB WorkingSetSize: 14.32MB PagefileUsage: 8.0664MB
Full run time is 1611.67 ms, Повторный запуск: 240.524 ms

stime.exe -quit javaw -jar drjava-beta-20160913-225446.jar JsonIterator.java
DiskIO: 97.992MB WorkingSetSize: 75.52MB PagefileUsage: 100.41MB
Full run time is 6860.405 ms, Повторный запуск: 4533.613 ms

stime.exe -splash -quit "C:\Program Files\SharpDevelop\5.1\bin\SharpDevelop.exe" kernel.cs
DiskIO: 127.4MB WorkingSetSize: 68.148MB PagefileUsage: 53.133MB
Full run time is 9752.181 ms, Повторный запуск: 3066.784 ms

Здесь тоже приходится применять обходной путь для Явы — после того, как окно приложения закрылось, пристреливаем javaw.exe

> Исходники программы stime и бинарник на GitHub

Выводы — загрузка фреймворка — очень дорогая операция, поскольку стоит большого количества рандомного ввода-вывода. Хотите быструю программу — делайте ее компактными средствами.

Ну а для подробной диагностики, на забываем про более подробные утилиты Руссиновича и средства профилирования для своего набора инструментов.