О, чувак, с чего начать?
Во-первых, я поражен, что это новость.Во-вторых, проблема не в том, что профилировщики плохие, а в том, что некоторые профилировщики плохие.Авторы создали одну, которая, по их мнению, является хорошей, просто избегая некоторых ошибок, которые они обнаружили в тех, которые они оценили.Ошибки распространены из-за некоторых постоянных мифов о профилировании производительности .
Но давайте будем позитивными.Если кто-то хочет найти возможности для ускорения, это действительно очень просто:
Выборка должна быть некоррелированной с состоянием программы.
Это означает, что происходитв действительно случайное время, независимо от того, находится ли программа во вводе-выводе (за исключением пользовательского ввода), или в ГХ, или в жестком цикле ЦП, или как угодно.
Выборка должен прочитать стек вызовов функций ,
, чтобы определить, какие операторы были "активными" во время выборки.Причина в том, что каждый сайт вызова (точка, в которой вызывается функция) имеет процентную стоимость, равную доле времени, которое он находится в стеке.(Примечание: статья полностью посвящена самовоспроизведению, игнорируя огромное влияние вызовов функций, которых можно было избежать в большом программном обеспечении. Фактически, причина, лежащая в основе gprof, заключалась в том, чтобы помочь найти эти вызовы.)
В отчетах должно отображаться процентов по строке (не по функциям).
Если определена «горячая» функция, в ней все равно приходится искать «горячие» линиикод учета по времени.Эта информация в примерах !Зачем это скрывать?
Почти универсальная ошибка (которую разделяет бумага) - слишком сильно беспокоиться о точности измерения и недостаточно о точности место .Например, вот пример настройки производительности , в котором был выявлен и устранен ряд проблем с производительностью, что привело к совокупному ускорению в 43 раза.Не обязательно было точно знать размер каждой проблемы перед ее решением, но нужно было знать ее местоположение.Феномен настройки производительности заключается в том, что решение одной проблемы за счет сокращения времени увеличивает процент оставшихся проблем, поэтому их легче найти.Пока любая проблема найдена и устранена, достигнут прогресс в направлении поиска и устранения всех проблем.Нет необходимости фиксировать их в порядке уменьшения размера, но важно точно их определить.
В отношении статистической точности измерения, если точка вызова находится в стеке в некоторый процент времени 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, так что это ожидаемая экономия, учитывая эти образцы.) ВСТАВЛЕНО: И коэффициент ускорения, который вы получаете, определяется другим распределением, BetaPrime и его среднее значение равно 4. Поэтому, если вы возьмете 3 семпла, увидите проблему на двух из них и устраните эту проблему, в среднем вы сделаете программу в четыре раза быстрее.
Самое время нампрограммисты сдули паутину с головы на предмет профилирования.
Отказ от ответственности - в статье не было ссылки на мою статью: Dunlavey, «Настройка производительности с учетом затрат на уровне команд, полученных из выборки из стека вызовов», Уведомления ACM SIGPLAN 42, 8 (август 2007 г.), стр. 4-8.