Каков наилучший способ измерения и отслеживания производительности по различным вызовам во время выполнения?

Question

Я пытаюсь оптимизировать производительность своего кода, но я не знаком с отладчиками или отладчиками xcode в целом. Можно ли отслеживать время выполнения и частоту звонков во время выполнения?

Представьте цепочку событий с рекурсивными вызовами за долю секунды. Какой лучший способ отследить, где процессор тратит большую часть своего времени?

Большое спасибо.

Редактировать: Может быть, это лучше спросить, сказав, как мне использовать инструменты отладки xcode для трассировки стека?

Answer 1

Вы хотите использовать встроенные инструменты для повышения производительности, которые называются «Инструменты», ознакомьтесь с Руководством по яблокам для Инструменты . В частности, вы, вероятно, хотите Системные инструменты . Есть также Руководство по настройке , которое может быть полезно для вас, и Акула .

Answer 2

Представьте цепочку событий с некоторыми рекурсивные вызовы за долю второй. Какой лучший способ отследить где процессор тратит большую часть своего времени?

Краткая версия предыдущего ответа.

1. Изучите IDE или отладчик. Убедитесь, что на нем есть кнопка «пауза», или вы можете прервать ее, когда ваша программа работает и занимает слишком много времени.

2. Если ваш код выполняется слишком быстро, чтобы его можно было приостановить вручную, оберните вокруг него временный цикл от 10 до 1000 раз.

3. Когда вы сделаете паузу, сделайте копию стека вызовов в каком-нибудь текстовом редакторе. Повторите несколько раз.

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

Не думайте об измерении микросекунд или подсчете вызовов. Подумайте о «проценте активного времени». Это то, что говорят вам образцы стека, и это примерно то, что вы сэкономите, если исправите это.

Это так просто.

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

Answer 3

Первое, что я говорю людям, - это признать разницу между

1) синхронизация подпрограмм и подсчет количества их вызовов и

2) поиск кода, который вы можете плодотворно оптимизировать.

Для (1) существуют профилировщики инструментов. Чтобы быть действительно успешным в (2), вам нужен редкий тип профилировщика. Вам нужен профилировщик выборки, который

• выборка всего стека вызовов, а не только счетчик программы

• выборок в произвольные часы настенного времени, а не только на ЦП, для выявления возможных проблем ввода-вывода

• выборки, когда вы этого хотите (не при ожидании ввода пользователя)

• для вывода дает для каждой строки кода, которая появляется в выборках стека , процентов выборок, содержащих эту строку . Это прямая мера общего времени, которое можно было бы сэкономить, если бы этой строки не было.

(на самом деле я делаю это вручную, прерывая программу под отладчиком.)

Не отвлекайтесь на проблемы, которых у вас нет, такие как

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

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

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

Важно понимать, чего ожидать. Многие программисты, используя традиционные профилировщики, могут получить улучшение на 20%, считают это потрясающим, считают профилировщик победителем и на этом останавливаются. Другие, работающие с большими программами, часто могут получить коэффициенты ускорения в 20 раз . Это делается путем исправления серии проблем , каждая из которых дает мультипликативный коэффициент ускорения. Как только профилировщик не может найти следующую проблему, процесс останавливается. Вот почему «достаточно хорошо» не достаточно хорошо.

Вот краткое объяснение метода.