В чем причина профилирования? Вы хотите: а) измерить время и получить график вызовов, или б) найти вещи, которые нужно изменить, чтобы сделать код быстрее? (Это не одно и то же.)
Если (b) вы можете использовать этот трюк , используя кнопку Пауза в Eclipse.
Добавлено: Может быть, это поможет передать некоторый опыт того, что проблемы на самом деле, и где вы можете ожидать их найти. Вот несколько простых примеров:
Сортировка вставки (порядок n ^ 2), где сортируемые элементы являются строками и сравниваются с помощью функции сравнения строк. Где горячая точка? в строке сравнения. В чем проблема? В том случае, когда вызывается сравнение строк. Если n = 10, это не проблема, но если n = 1000, внезапно это занимает много времени. Точка, где вызывается сравнение строк, называется «холодной», но в этом проблема. Небольшое количество выборок стека вызовов точно определяет его.
Приложение, которое загружает плагины, занимает много времени для запуска. Профилировщик говорит, что в основном все "холодно". Что-то, что измеряет время ввода-вывода, говорит, что это почти все время ввода-вывода, которое выглядит как то, что вы можете ожидать, поэтому оно может показаться безнадежным. Но образцы стека показывают, что при чтении ресурсной части dll-плагина с целью перевода строковых констант на местный язык большой процент времени уходит со стеком глубиной около 20 слоев. Исследуя далее, вы обнаружите, что большинство переводимых строк не относятся к тому типу, который на самом деле требует перевода. Их просто поместили «на всякий случай», им, возможно, понадобился перевод, и никогда не думали, что это может вызвать проблемы с производительностью. Исправление этой проблемы приносит значительную экономию времени.
Так что принято думать о «горячих точках» и «узких местах», но большинство программ, особенно более крупные, склонны иметь проблемы с производительностью в виде вызовов функций, требующих работы, которая на самом деле не требуется сделанный. К счастью, они отображаются в стеке вызовов в течение времени, которое они тратят.