Представьте, что у вас есть приложение командной строки, которое принимает входной файл и что-то с ним делает. Теперь представьте, что вы хотите протестировать / профилировать это приложение. Если бы это была Visual Studio, вы бы просто выбрали метод профилирования (выборка / инструментирование), и VS запустил бы приложение для вас и собирал данные, пока программа завершается. Но, насколько я понимаю, в VisualVM подобной функциональности нет. Вы должны запустить свое приложение, затем выбрать его в VisualVM, а затем явно запустить выборку / профилирование. Проблема в том, что иногда выполнение программы с определенными входными данными занимает меньше времени, чем требуется для настройки VisualVM. Также при таком подходе нет возможности пакетировать приложение профиля. Кто-то предложил запустить приложение в режиме отладки из Eclipse и установить точку останова где-нибудь в начале метода main (). Затем настройте VisualVM и продолжите выполнение. Но у меня есть подозрение, что работа в режиме Debug vs Release сама по себе влияет на производительность. Предложения?
Приложение для профилирования с помощью VisualVM
Ответы (2)
Появился новый плагин Startup Profiler для VisualVM 1.3.6, который позволяет профилировать приложение из его запуск. Дополнительную информацию см. В этой статье.
Если программа выполняет ввод-вывод, сэмплер Visual Studio не будет видеть этот ввод-вывод, потому что он является «семплером ЦП» (даже если почти все время тратится на ожидание ввода-вывода).
Если вы используете Instrumentation, вы не увидите никакой информации на уровне строки, потому что она суммируется только на уровне функций.
Я использую эту технику.
Если программа выполняется слишком быстро для выборки, просто поместите вокруг нее временный внешний цикл, скажем, на 100 или 1000 итераций.
Разница между режимами отладки и выпуска будет практически нулевой, если только вы не проведете значительную часть времени в жестких циклах в своем коде, где циклы не содержат никаких вызовов функций, ИЛИ если вы выполнение операций со структурой данных, которые требуют большого количества проверок в библиотеках.
Если да, то ваши образцы покажут, что это так, и вы будете знать, что Release изменит скорость.
Что касается пакетного профилирования, то я не знаю. Я просто слежу за общей пропускной способностью программы. Если есть какой-то ввод, который, кажется, занимает слишком много времени, я провожу процедуру выборки в программе с этим вводом, смотрю, в чем проблема, и исправляю ее.
