Работают ли классы фильтрации для профилирования процессора в Java VisualVM? - PullRequest
6 голосов
/ 26 августа 2011

Я хочу отфильтровать, какие классы профилируются процессором в Java VisualVm (версия 1.7.0 b110325). Для этого я попытался в Profiler -> Settings -> CPU-Settings установить « Profile only classes » для моего тестируемого пакета, но это не имело никакого эффекта. Затем я попытался избавиться от всех классов java. * И sun. *, Установив их в « Не профилировать классы », что также не имело никакого эффекта.

Это просто ошибка? Или я что-то упустил? Есть ли обходной путь? Я имею в виду, кроме:

Я хочу сделать это главным образом, чтобы получить половину правильного процента потребляемого процессора на метод. Для этого мне нужно избавиться от надоедливых измерений, например для sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (около 70%). Многие пользователи, кажется, имеют эту проблему, см., Например,

Ответы [ 2 ]

10 голосов
/ 27 августа 2011

Причина, по которой вы видите sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() в профиле, заключается в том, что вы оставили опцию Профиль новых Runnables выбранным.

Кроме того, если вы сделали снимок сеанса профилирования, вы сможете увидеть весь стек вызовов для любого метода горячей точки - таким образом, вы можете перейти от метода run() к собственным методам логики приложения,отфильтровывать шум, генерируемый параметром Profile new Runnables .

0 голосов
/ 27 августа 2011

ОК, поскольку ваша цель - сделать код максимально быстрым, позвольте мне предложить, как это сделать. Я не специалист по VisualVM, но я могу рассказать вам, что работает. (На самом деле только несколько профилировщиков говорят вам, что вам нужно знать, а именно - какие строки вашего кода находятся в стеке, что составляет значительную долю времени настенного времени .)

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

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

По сути, идея заключается в том, что вы получаете (небольшое, например, 10) количество стековых выборок, взятых в случайное время настенных часов. Каждый образец состоит (очевидно) из списка сайтов вызовов, и, возможно, сайта без вызовов в конце. (Если сэмпл находится во время ввода-вывода или в спящем режиме, он завершится системным вызовом, что очень хорошо. Это то, что вы хотите знать.)

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

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

...