Если профайлер не является ответом, какие у нас есть другие варианты?

После просмотра презентации "Беспокойство о производительности" Джошуа Блоха я прочитал статью, которую он предложил в презентации "Оценка точности Java-профилей" . Цитируя вывод:

Наши результаты тревожат, потому что они указывают на то, что некорректность профайнера распространена во многих наших семи тестах и в двух производственных JVM - и значительных - все четыре современные профессионалы производят неправильные профили. некорректный профили могут легко заставить аналитика производительности тратить время на оптимизацию холодных методов, которые будут иметь минимальное влияние на производительность. Мы показываем, что прогностический профайлер, не использующий доходность точки для отбора проб не страдают от вышеуказанных проблем

Вывод статьи состоит в том, что мы не можем поверить в результат профилировщиков. Но тогда, какова альтернатива использования профилографов. Должны ли мы вернуться и просто использовать наше чувство для оптимизации?

ОБНОВЛЕНИЕ. Точка, которая, по-видимому, отсутствует в обсуждении, является эффектом наблюдателя. Можем ли мы построить профилировщик, который действительно "эффект наблюдателя"?

Ответ 1

О, мужик, с чего начать?

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

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

Отбор проб должен быть несовместим с состоянием программы.
Это означает, что это происходит по-настоящему случайным образом, независимо от того, работает ли программа в режиме ввода-вывода (кроме ввода пользователя) или в GC или в узком цикле процессора или что-то еще.
Сэмплинг должен читать стек вызовов функций,
чтобы определить, какие утверждения были "активными" во время выборки. Причина в том, что каждый сайт вызова (точка, с которой вызывается функция) имеет процентную стоимость, равную половине времени, которое она находится в стеке. (Примечание: статья полностью посвящена самообслуживанию, игнорируя массовое воздействие предотвращаемых вызовов функций в большом программном обеспечении. Фактически причина оригинального gprof заключалась в том, чтобы помочь найти эти вызовы.)
Отчетность должна показывать процент за строкой (не по функциям).
Если "горячая" функция идентифицирована, все еще нужно искать ее внутри "горячих" строк кода, учитывающих время. Эта информация находится в образцах! Зачем скрывать это?

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

В отношении статистической точности измерения, если точка вызова находится в стеке, часть процента времени F (например, 20%) и N (например, 100) выборок случайного времени берутся, а затем количество выборок, которые показать, что точка вызова является биномиальным распределением со средним значением = NF = 20, стандартное отклонение = sqrt (NF (1-F)) = sqrt (16) = 4. Таким образом, процент образцов, которые показывают это, будет составлять 20% +/- 4%. Так это точно? Не совсем, но проблема была найдена? Точно.

На самом деле, чем больше проблема, тем больше процентов, чтобы найти ее. Например, если взяты 3 выборки, и на 2 из них отображается точка вызова, это, скорее всего, будет очень дорогостоящим. (В частности, это следует за бета-распределением. Если вы генерируете 4 одинаковых 0,1 случайных числа и сортируете их, распределение третьего - это распределение стоимости для этой точки вызова. Это означает, что (2 + 1)/(3 + 2) = 0,6, так что это ожидаемая экономия, учитывая эти образцы.) INSERTED: А коэффициент ускорения, который вы получаете, регулируется другим дистрибутивом BetaPrime, а его среднее значение равно 4. Поэтому, если вы берете 3 образца, см. Проблему на 2 из них, и устранить эту проблему, в среднем вы будете делать программу в четыре раза быстрее.

Настало время, когда мы программисты выбивали паутину из головы на тему профилирования.

Отказ от ответственности - документ не ссылался на мою статью: Dunlavey, "Настройка производительности с затратами на уровне инструкций, полученными из выборки вызовов", ACM SIGPLAN Уведомления 42, 8 (август 2007 г.), стр. 4-8.

Ответ 2

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

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

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

Ответ 3

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

У меня есть опыт работы с http://www.dynatrace.com/en/, и я могу сказать вам, что он очень хорошо разбирается в низко висящих фруктах.

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

Ответ 4

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

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

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

Ответ 5

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