Профилирование приложения с VisualVM

Question

Представьте, что у вас есть приложение командной строки, которое принимает входной файл и что-то делает с ним. Теперь представьте, что вы хотите попробовать/профилировать это приложение. Если бы это была Visual Studio, вы бы просто выбрали метод профилирования (выборка/контрольно-измерительная техника), и VS запустил приложение для вас и собирал данные, пока программа завершится. Но, насколько я вижу, в VisualVM нет аналогичной функциональности. Вы должны запустить свое приложение, а затем выбрать его в VisualVM, а затем явно начать выборку/профилирование. Проблема в том, что иногда выполнение программы с определенными входными данными занимает меньше времени, чем требуется для установки VisualVM. Кроме того, при таком подходе нет возможности для пакетного приложения профиля. Кто-то предложил запустить приложение в режиме отладки из Eclipse и установить точку останова где-то в начале метода main(). Затем настройте VisualVM и продолжите выполнение. Но у меня есть подозрение, что работа в режиме Debug vs Release сама по себе влияет на производительность. Предложения?

Answer 1

Для VisualVM 1.3.6 есть новый Startup Profiler plugin, который позволяет вам профилировать приложение из его запуска. См. Это article для получения дополнительной информации.

Answer 2

Если программа выполняет операции ввода-вывода, то сэмплер Visual Studio не увидит ввода-вывода, потому что это «процессорный пробоотборник» (даже если почти все время затрачено на ожидание ввода-вывода).

Если вы используете Instrumentation, вы не увидите никакой информации на линейном уровне, поскольку она суммируется только на уровне функции.

Я использую this technique.

Если программа работает слишком быстро, чтобы пробовать, просто поместите временный внешний цикл вокруг, скажем, 100 или 1000 итераций.

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

Если вы, то ваши образцы покажут вам, и вы узнаете, что Release сделает разницу в скорости.

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