Как показать, сколько раз функции вызывались в Instruments Time Profiler

Question

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

Кроме того, я не получаю Self и # Self. Что означают эти два числа?

Answer 1

Есть несколько других способов сделать это.Очевидно, что нужно создать статический счетчик посещений и NSLog, который генерирует и увеличивает счетчик.Это навязчиво, но я нашел способ сделать это с помощью lldb.

1. Установить точку останова
2. Запускать программу до тех пор, пока вы не достигнете точку останова в первый раз и не запомните номер точки останова нав правой части строки, по которой вы нажали (например, «Поток 1: точка останова 7.1», обратите внимание на 7.1)
3. Щелкните контекстную точку останова и выберите «Изменить точку останова»
4. Оставьте условие пустым ивыберите «Добавить действие»
5. Выберите «Команда отладчика»
6. В командной строке введите «список точек останова 7.1» (используя номер точки останова для точки останова из шага 2).Я полагаю, что вы можете использовать «info break», если вы используете gdb.
7. Проверить параметры «Автоматически продолжить после оценки»
8. Продолжить

Теперь вместо остановки llvm выдаст информацию о точке останова, в том числе о том, сколько раз она была пройдена.

Что касается обсуждения между Гленном и Майком предыдущего ответа, я опишу проблему с производительностью.где счетчик выполнения функции был полезен: в моем приложении было определенное действие, при котором производительность значительно снижалась при каждом выполнении действия.Профилировщик времени Instruments показал, что каждый раз, когда выполнялось действие, определенная функция выполнялась вдвое дольше, чем раньше, до тех пор, пока приложение быстро не зависло, если действие выполнялось повторно.С помощью счетчика я смог определить, что при каждом выполнении функция вызывается в два раза чаще, чем во время предыдущего выполнения.Тогда было довольно легко найти причину, которая заключалась в том, что кто-то перерегистрировал уведомление в NotificationCenter о каждом выполнении события.Это приводило к удвоению количества вызовов обработчиков ответов при каждом выполнении и, таким образом, к удвоению «стоимости» функции каждый раз.Зная, что оно удваивается, потому что его вызывали в два раза чаще, а не потому, что производительность просто ухудшалась, я стал смотреть на последовательность вызова, а не по причинам, из-за которых сама функция могла со временем ухудшаться.

Answer 2

Кажется, вы не можете использовать Time Profiler для подсчета вызовов функций. Этот вопрос , кажется, касается потенциальных методов подсчета.

W / отношение к self и # self :

Self равно "Количество раз, которое символ вызывает себя." в соответствии с Apple Docs на Time Profiler.

Судя по тому, как выглядят числа, кажется, что self - это суммарная продолжительность отсчетов, у которых этот символ находился в нижней части трассы стека. Это сделало бы:

• # self: количество выборок, где этот символ находился внизу трассы стека
• % self: процент собственных выборок относительно общего количества отображаемых в данный момент деревьев вызовов
  • (например, - #self / total samples).

Так что это не скажет вам, сколько раз был вызван метод. Но это даст вам представление о том, сколько времени затрачивается на метод или меньше в дереве вызовов.

ПРИМЕЧАНИЕ: Я тоже не уверен в различных значениях «я», хотя. Очень хотелось бы, чтобы кто-то ответил на это авторитетно. Прибыл сюда в поисках этого ...

Answer 3

Хотя это интересно, зная, сколько раз звонил, не имеет никакого отношения к тому, сколько времени в них тратится.Вот что такое Time Profiler.Фактически, поскольку он выполняет выборку, он не может ответить сколько раз.

Answer 4

ЕСЛИ ваша цель - выяснить, что вам нужно исправить, чтобы сделать программу максимально быстрой,

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

Посмотрите на мой ответ на этот вопрос , в частности пункты 6 и 8.

РЕДАКТИРОВАТЬ: Для дальнейшего уточнения, предположим, что ниже приведен график выполнения программы. Часть этого времени (в данном случае около 50%) тратится на деятельность, которую можно удалить, если вы знаете, что это такое, например, ненужный скрытый ввод-вывод, чрезмерные вызовы new, уведомления о сбеге или «незначительное» " проверка данных. Если взята выборка случайного времени, у нее есть 50% -ная вероятность возникновения этой активности, и проверка стека вызовов и / или программных переменных показывает, что он делает что-то, что можно удалить. Затем, если будет взято 10 таких образцов, активность будет видна примерно на 5 из них, независимо от того, происходит ли эта активность в течение нескольких больших промежутков времени или множества маленьких. Действие может состоять из нескольких строк кода в функции, выполняющей что-то ненужное, или может быть чем-то гораздо более обобщенным. В любом случае, вы узнаете это, исправите это и получите примерно в 2 раза больше ускорения. Подсчет вызовов и самостоятельное время ничего не влияют на этот процесс.