Странные результаты профилирования: определенно появляется метод без узких мест - PullRequest
1 голос
/ 07 мая 2010

Я профилирую программу, используя профилирование выборки в YourKit и JProfiler, а также «вручную» (я запускаю ее и нажимаю Ctrl-Break несколько раз, чтобы получить дампы потоков).

Все три метода дают мне очень странные результаты: несколько десятков процентов времени, проведенного в трехстрочном методе , который даже не выполняет никакого выделения или синхронизации и не имеет циклов и т. Д. Кроме того, после того, как я превратил этот метод в NOP и даже полностью удалил его вызов, наблюдаемая производительность программы не изменилась вообще (хотя она получила незначительную утечку памяти, поскольку это был метод для освобождения дешевого ресурса).

Я думаю, что это может быть из-за ограничений, которые JVM накладывает на моменты, когда может быть получена трассировка стека потока, и почему-то получается, что в моей программе это именно те моменты, когда этот метод вызывается, хотя в этом нет абсолютно ничего особенного или контекст, в котором он вызывается.

Чем можно объяснить это явление? Каковы вышеупомянутые ограничения? Какие дополнительные измерения я могу предпринять, чтобы прояснить ситуацию?

Ответы [ 3 ]

0 голосов
/ 07 мая 2010

Когда вы несколько раз делали Ctrl-Break и получали дампы потоков, мне любопытно, что вы видели. Стеки вызовов, на мой взгляд, самая полезная информация. Если ваш 3-лайнер находится в стеке большой процент времени, то вы можете понять почему, посмотрев, откуда он вызывается, откуда , откуда вызывается и т. Д. ответственность за время, потраченное как 3-х лайнер.

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

0 голосов
/ 07 мая 2010

Некоторые сторонние библиотеки приводят к тому, что дампы кучи становятся полностью бесполезными из-за непредвиденных шаблонов использования, например, если используется cglib , это замаскирует действительную причину проблем и вместо этого покажет много Прокси-объекты (, если я правильно помню ) вместо этого заполняют виртуальную машину.

Короче говоря, генерация и отражение кода могут привести к неправильной статистике.

0 голосов
/ 07 мая 2010

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

...