Как показать количество раз, когда функции вызываются в Инструментах Time Profiler
Я пробовал все возможные поля, но не могу найти количество раз, когда вызываются функции.
![enter image description here]()
Кроме того, я не получаю Self
и # Self
. Что означают эти два числа?
Ответы
Ответ 1
Есть несколько других способов сделать это. Очевидно, что для создания счетчика статического удара и NSLog, который испускает и увеличивает счетчик. Это навязчиво, хотя и я нашел способ сделать это с помощью lldb.
- Установить точку останова
- Выполняйте программу до тех пор, пока вы не нажмете точку останова в первый раз и не заметите номер точки останова в правой части линии, на которую вы попали (например, "Thread 1: точка останова 7.1", обратите внимание на 7.1)
- Контекст нажмите на точку останова и выберите "Изменить точку останова"
- Оставьте условие пустым и выберите "Добавить действие"
- Выберите команду "Отладчик"
- В командной строке введите "список контрольных точек 7.1" (используя номер точки останова для вашей точки останова с шага 2). Я считаю, что вы можете использовать "info break", если вы используете gdb.
![enter image description here]()
- Проверить параметры "Автоматическое продолжение после оценки"
![Breakpoint setup]()
- Продолжить
Теперь, вместо остановки, llvm выдаст информацию о точке останова, включая количество раз, которое она была передана.
Что касается обсуждения между Гленном и Майком в предыдущем ответе, я опишу проблему с производительностью, в которой был полезен счет выполнения функции: у меня было определенное действие в моем приложении, где производительность значительно снижалась при каждом выполнении действия. Профилировщик "Инструменты времени" показал, что каждый раз, когда действие выполнялось, определенная функция выполнялась в два раза до тех пор, пока время до того, как приложение быстро зависает, если действие было выполнено повторно. С помощью count я смог определить, что при каждом выполнении функция вызывалась в два раза больше, чем во время предыдущего выполнения. Тогда было довольно легко найти причину, которая оказалась в том, что кто-то перерегистрировался для уведомления в NotificationCenter при каждом выполнении события. Это привело к удвоению количества вызовов обработчика ответа при каждом выполнении и, таким образом, удвоении "стоимости" функции каждый раз. Зная, что он удваивается, потому что он был вызван в два раза больше, а не потому, что производительность только ухудшалась, заставила меня посмотреть на вызывающую последовательность, а не по причинам, которые сама функция может ухудшиться с течением времени.
Ответ 2
Хотя это интересно, зная количество раз называемых, не имеет никакого отношения к тому, сколько времени в них потрачено. Это то, о чем говорит Time Profiler. Фактически, поскольку он выполняет выборку, он не может ответить сколько раз.
Ответ 3
Кажется, вы не можете использовать Time Profiler для подсчета вызовов функций. Этот question, по-видимому, относится к потенциальным методам подсчета.
W/отношение к себе и #self:
Self
: "Количество раз, когда символ вызывает себя". в соответствии с Документами Apple в профиле времени.
Из того, как выглядят цифры, кажется, что Self
- это суммарная длительность отсчетов, у которых этот символ находился в нижней части трассировки стека. Это сделало бы:
-
# self
: количество выборок, в которых этот символ находился в нижней части трассировки стека
-
% self
: процент собственных выборок относительно общих выборок отображаемого в настоящее время дерева вызовов
- (например,
#self
/total samples
).
Итак, это не скажет вам, сколько раз был вызван метод. Но это даст вам представление о том, сколько времени потрачено на метод или ниже в дереве вызовов.
ПРИМЕЧАНИЕ. Я тоже не уверен в различных "я" значениях. Хотел бы, чтобы кто-то ответил на это авторитетно. Прибыл сюда в поисках этого...
Ответ 4
Если ваша цель - выяснить, что вам нужно исправить, чтобы сделать программу как можно быстрее,
Количество вызовов и время автономной работы могут быть интересными, но неактуальными.
Посмотрите мой ответ на этот вопрос, в частности пункты 6 и 8.
РЕДАКТИРОВАТЬ: Чтобы прояснить точку далее, предположим, что следующая временная шкала выполнения программы. Некоторое время (в этом случае около 50%) тратится на деятельность, которая может быть удалена, если вы знаете, что это такое, например, ненужные захороненные операции ввода-вывода, чрезмерные вызовы на new
, уведомления о беглых сообщениях или "незначительные" валидация данных. Если выборка случайного времени выполняется, у нее есть 50% вероятность появления в этом действии, а проверка стека вызовов и/или переменных программы показывает, что он делает что-то, что можно удалить. Затем, если взять 10 таких образцов, активность будет видна примерно на 5 из них, независимо от того, происходит ли действие в нескольких больших кусках времени или во многих мелких. Активность может быть несколькими строками кода в функции, делающей что-то ненужное, или это может быть нечто гораздо более обобщенное. Независимо от того, вы его узнаете, исправьте и получите примерно 2 коэффициента ускорения. Количество вызовов и время автономной работы ничего не способствуют этому процессу.
![введите описание изображения здесь]()