Не видьте мои собственные методы приложения в Java VisualVM
Я пытаюсь представить свое приложение Java, только узнать методы, в которых проводится большая часть времени. Учитывая плохие реакции здесь на TPTP, я думал, что дам Java VisualVM движение.
Казалось довольно простым использовать - за исключением того, что я, может казаться, не получаю ничего последовательного или полезного из него.
Я, может казаться, не вижу, что что-либо касается МОЕГО СОБСТВЕННОГО кода - все, что я получаю, целый набор вызовов к вещам как Java.* методы.
Я попытался ограничить инструментарий только своими собственными пакетами, который, кажется, сокращает количество оснащенных методов, но тем не менее я, когда-либо кажется, не вижу свое собственное.
Каждый раз, когда я работаю, я получаю переменные числа оснащенных методов, в пределах от 10-х к 1000-м. Я попытался включить сон в начале своего приложения, удостовериться, что я бужу VisualVM и работающий, прежде чем мое приложение начнет делать что-либо интересное, удостоверяться, что это является профильным, когда интересный материал работает.
Есть ли что-то, что я должен сделать, чтобы гарантировать, что мои классы оснащены? Там синхронизируют проблемы?.. как, должны ожидать классов, которые будут загружены и т.д.? Я также попытался выполнить кишки кода дважды, удостовериться, что весь код действительно становится осуществленным...
Я просто запускаю приложение, с основным, от Eclipse. Я попытался использовать интеграцию Eclipse так, чтобы VisualVM запустил, когда я запускаю приложение - результатами является то же. Я также попытался экспортировать приложение как выполнимое приложение и выполнить его автономный из командной строки, а не через Eclipse - тот же результат.
Мое приложение не является длительным веб-приложением и т.д. - просто основное, которое называет некоторые другие из моих собственных классов, чтобы сделать некоторую обработку, затем выходит.
Я был бы благодарен за любой совет о том, что я мог бы делать неправильно!:)
Спасибо!
1 ответ
Я полагаю, это не чисто академический вопрос - вы бы хотели посмотреть, сможете ли вы заставить приложение работать быстрее. Я предполагаю, что вы также не против немного нестандартного мышления. Есть много популярных представлений о производительности, которые на самом деле довольно расплывчаты.
Например, вы говорите, что ищете «методы, на которые тратится больше всего времени». Если под этим вы имеете в виду «собственное время» (счетчик программы на самом деле в методе), то, вероятно, очень мало, если у вас нет интенсивных циклов. Методы обычно проводят время, вызывая другие методы, иногда выполняя операции ввода-вывода.
Еще одна нечеткая идея заключается в том, что измерение времени выполнения метода или подсчет количества вызовов может очень многое сказать о том, где находятся узкие места. Узкие места - это определенные строки кода, а не методы, поэтому, даже если вы приблизительно знаете, где искать, вы все равно играете в детектива.
Итак, это несколько нечетких идей. Вот еще куча. Позвольте мне предложить, как следует думать об этом и как это приводит к результатам.
Когда вы в конечном итоге что-то исправляете, время выполнения сокращается на несколько процентов, например (выберите число) на 30%, верно? (В противном случае вы ничего не исправили.) Хорошо, в течение этих 30% он что-то делал, то, что ему не нужно было делать, потому что позже вы от этого избавились. Итак, вы не должны измерять. Вам и нужно узнать , что он делает в это время, чтобы вы знали, от чего избавляться.
Самый простой способ - это случайным образом "поставить на паузу" 10 (или некоторое количество) раз. Понять, что он делает и почему, посмотрев на стек вызовов и, возможно, на некоторые данные. Примерно в 3 случаях вы увидите, как он делает то, от чего вы можете избавиться.
Вы узнаете приблизительно , сколько он сэкономит, посмотрев, какой процент образцов показывает это. Приблизительное значение достаточно хорошо. Вы можете легко увидеть, сколько именно времени сэкономлено, посмотрев время до и после.
Тогда не останавливайтесь. Вы сделали приложение быстрее. Сделайте это снова и сделайте это еще быстрее. Рано или поздно вы достигнете точки, когда не сможете сделать это быстрее, но, вероятно, это займет более одного шага.