Профилирование коротко работающих Java-приложений имеет пару технических трудностей:
- Инструменты профилирования обычно работают путем периодической выборки регистра SP процессора или ПК, чтобы увидеть, где в данный момент выполняется приложение. Если ваша заявка недолговечная, для получения точного изображения может быть взято недостаточно образцов.
Вы можете решить эту проблему, изменив приложение так, чтобы оно запускалось несколько раз в цикле, как предлагает @Mike. У вас будут проблемы, если ваше приложение вызовет System.exit(), но главная проблема заключается в ...
- Характеристики производительности недолговечного Java-приложения могут быть искажены эффектами разогрева JVM. Много времени будет потрачено на загрузку классов, необходимых вашему приложению. Затем ваш код (и код библиотеки) будет немного интерпретироваться, пока JIT-компилятор не выяснит, что нужно скомпилировать в нативный код. Наконец, JIT-компилятор потратит время на выполнение своей работы.
Я не знаю, пытаются ли профилировщики компенсировать эффекты разогрева JVM. Но даже если они это и делают, эти эффекты влияют на реальное поведение ваших приложений, и разработчик приложения не так уж много может сделать, чтобы смягчить их.
Возвращаясь к моему предыдущему пункту ... если вы запускаете недолговечное приложение в цикле, вы фактически делаете что-то, что изменяет его обычный шаблон выполнения и удаляет компонент прогрева JVM. Поэтому, когда вы оптимизируете метод, который занимает (скажем) 50% времени выполнения в модифицированном приложении, это действительно 50% времени без учета разогрева JVM . Если разогрев JVM использует, скажем, 80% времени выполнения, когда приложение выполняется нормально, вы фактически оптимизируете 50% из 20% ... и это не стоит усилий.