Если профилировщик не является ответом, какие еще варианты у нас есть?
После просмотра презентации" Performance Anxiety " Джошуа Блоха я прочитал статью, предложенную им в презентации "оценка точности Java-профилировщиков". Цитируя заключение:
Вывод статьи состоит в том, что мы не можем действительно верить результатам профилировщиков. Но тогда, какова альтернатива использования профилировщиков? Должны ли мы вернуться назад и просто использовать наши чувства для оптимизации?Наши результаты вызывают беспокойство, поскольку они указывают на то, что некорректность профилировщика распространена повсеместно-встречается в большинстве из наших семи критериев и в двух производственных СПМ-и значительна-во всех четырех из них. государство-оф-искусство профайлеры выдавать неправильные профили. Неправильный профили могут легко заставить аналитика производительности тратить время на оптимизацию холодных методов, которые будут иметь минимальное влияние на производительность. Мы покажем, что профайлер доказательства концепции, который не использует выход точки для выборки не страдают от вышеуказанных проблем
Обновление : Один момент, который, кажется, упущен в обсуждении, - этоЭффект Наблюдателя . Можем ли мы построить профилировщик, который действительно "Эффект Наблюдателя " -свободный?
5 ответов:
О, парень, с чего начать?
Во-первых, я поражен, что это новость. Во-вторых, проблема не в том, что профилировщики плохие, а в том, что Некоторые профилировщики плохие. Авторы построили тот, который, по их мнению, хорош, просто избегая некоторых ошибок, которые они обнаружили в тех, которые они оценивали. Ошибки распространены из-за некоторых стойких мифов о профилировании производительности . Но давайте будем позитивными. Если кто-то хочет найти возможности для ускорения, это действительно очень просто:Почти универсальная ошибка (которую разделяет статья) заключается в том, что слишком много внимания уделяется точности измерения и недостаточно точности определения местоположения . Например, вот пример настройки производительности в которой был выявлен и исправлен ряд проблем с производительностью,что привело к увеличению скорости в 43 раза. Не было необходимости точно знать размер каждого из них. проблема, прежде чем исправить его, но знать его местоположение. Феномен настройки производительности заключается в том, что устранение одной проблемы, сокращая время, увеличивает процент оставшихся проблем, поэтому их легче найти. До тех пор, покалюбая проблема будет найдена и исправлена, будет достигнут прогресс в направлении цели нахождения и исправления всех проблем. Нет необходимости фиксировать их в порядке уменьшения размера,но важно точно определить их.
Выборка должна бытьнекоррелированной с состоянием программы.
Это означает, что происходит в действительно случайное время, независимо от того, находится ли программа в режиме ввода-вывода (за исключением пользовательского ввода), или в GC, или в узком цикле процессора, или что-то еще.Выборка должна Читать стек вызовов функций,
чтобы определить, какие утверждения были "активны" во время выборки. Причина в том, что каждый узел вызова (точка, в которой находится функция вызывается) имеет процентную стоимость, равную доле времени, которое он находится в стеке. (Примечание: статья посвящена исключительно самостоятельному времени, игнорируя огромное влияние предотвратимых вызовов функций в большом программном обеспечении. На самом деле, причина, стоящая за оригинальнымgprof, заключалась в том, чтобы помочь найти эти вызовы.)Отчет должен показывать проценты по строке (не по функции).
Если" горячая "функция идентифицирована, то внутри нее все равно нужно искать "горячие" строки кода, учитывающие время. Эта информация находится в образцах ! Зачем это скрывать?По вопросу статистической точности измерение, если точка вызова находится в стеке в течение некоторого процента времени F (например, 20%), и берется N (например, 100) выборок случайного времени, то число выборок, показывающих точку вызова, является биномиальным распределением, со средним = NF = 20, стандартным отклонением = sqrt(NF(1-F)) = sqrt(16) = 4. Таким образом, процент образцов, которые показывают это, будет 20% +/- 4%. Так это точно? Не совсем, но была ли проблема найдена? Точно.
На самом деле, чем больше проблема, выраженная в процентах, тем меньше выборок. необходимы, чтобы найти его. Например, если взяты 3 образца, и точка вызова отображается на 2 из них, это, скорее всего, будет очень дорого. (В частности, он следует за бета-дистрибутивом. Если вы сгенерируете 4 однородных 0,1 случайных числа и отсортируете их, распределение 3-го числа будет распределением стоимости для этой точки вызова. Это подлость такая (2+1)/(3+2) = 0.6, так что это ожидаемая экономия, учитывая эти образцы.) Вставлено: и коэффициент ускорения, который вы получаете, определяется другим распределением, Бетаприм, и его среднее значение равно 4. Таким образом, если вы возьмете 3 образца, увидите проблему на 2 из них и устраните эту проблему, в среднем вы сделаете программу в четыре раза быстрее.Нам, программистам, давно пора выбросить паутину из головы на тему профилирования.
Отказ от ответственности-в статье не было ссылки на мою статью: Dunlavey, "настройка производительности с затратами на уровне инструкций, полученными из выборки стека вызовов", ACM SIGPLAN Notices 42, 8 (Август, 2007), стр.
Если я правильно понял, в статье говорится только о профилировании на основе выборки. Многие профилировщики также выполняют профилирование на основе инструментария. Он гораздо медленнее и имеет некоторые другие проблемы, но он не должен страдать от предвзятости, о которой говорится в статье.
Вывод статьи состоит в том, что мы не могу по-настоящему поверить в результат профилировщики. Но тогда, что же такое альтернатива использования профилировщиков.
Нет. Вывод статьи заключается в том, что современные профилировщики' методы измерения имеют специфические дефекты. Они предлагают исправить ситуацию. Статья написана совсем недавно. Я ожидал бы, что профилировщики в конечном счете реализуют это исправление. До тех пор даже дефектный профилировщик все еще намного лучше, чем "чувство".
Если вы не создаете приложения bleeding edge, которые нуждаются в каждом цикле процессора, то я обнаружил, что профилировщики-это хороший способ найти 10% самых медленных частей вашего кода. Как разработчик, я бы сказал, что это должно быть все, что вас действительно волнует почти во всех случаях.
У меня есть опыт работы с http://www.dynatrace.com/en и я могу сказать вам, что он очень хорошо находит низко висящие плоды.
Профилировщики похожи на любой другой инструмент, и у них есть свои причуды, но я бы доверяйте им больше, чем человеку в любой день, чтобы найти горячие точки в вашем приложении, чтобы посмотреть.
Если вы не доверяете профилировщикам, то вы можете перейти в режим паранойи, используя аспектно-ориентированное программирование, обертывание вокруг каждого метода в вашем приложении, а затем с помощью регистратора регистрировать каждый вызов метода.
Ваше приложение действительно замедлится, но, по крайней мере, у вас будет точное количество раз, когда вызывается каждый метод. Если вы также хотите узнать, сколько времени занимает выполнение каждого метода, оберните вокруг каждого метода perf4j.
После сброса всех этих статистика в текстовые файлы, используйте некоторые инструменты, чтобы извлечь всю необходимую информацию,а затем визуализировать ее. Я думаю, что это даст вам довольно хороший обзор того, как медленно ваше приложение в определенных местах.
На самом деле профилирование лучше проводить на уровне базы данных. Большинство корпоративных баз данных имеют возможность отображать основные запросы в течение определенного периода времени. Начните работать над этими запросами, пока верхние не опустятся до 300 мс или меньше, и вы добьетесь большого прогресса. Профилировщики полезны для демонстрации поведения кучи и для идентификации заблокированных потоков, но лично я никогда не получал большой тяги с командами разработчиков по идентификации горячих методов или больших объекты.