Программа профайлер что это такое

Профайлинг. Какие инструменты для диагностики проблем производительности вы знаете(profiler, deep profiling, frame debugger, memory profiling, profiling on device)?

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

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

Если мы хотим активировать профайлер в приложении, следует в окне Build Settings (File→Build Settings) включить параметры Autoconnect Profiler и Development Build. После запуска приложения профайлер станет запускаться автоматически. Вдобавок к этому, вы можете подключить профайлер в Profiler Controls, используя выпадающий список в редакторе.

Кто такие профайлеры

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

Выполняем профилирование в редакторе

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

Deep Profile

Это режим, в котором происходит отдельная запись вызовов каждого метода, в результате чего обеспечивается чёткое представление дерева методов. Тут следует вспомнить, что, начиная с Unity версии 2017.3, режим Deep Profile работает не только в редакторе, но также на Android и Desktop с применением бэкенда Mono.

Чтобы включить режим Deep Profile, задействуйте такой аргумент командной строки, как -deepprofiling. А если хотите включить данный режим на Android, вам подойдёт аргумент adb.

~$ adb shell am start -n com.company.game/com.unity3d.player.UnityPlayerActivity -e ‘unity’ ‘-deepprofiling’

Профилируем память в редакторе

Процесс профилирования памяти в редакторе полезен для понимания общей модели памяти, однако малополезен для фактических показателей конкретных устройств.

Здесь нужно отметить следующее: — во время выполнения у каждого меша флаг read/write установлен вне зависимости от значения Read/Write Enabled в настройках импорта ассета. В результате удваивается память мешей, отображаемая в профайлере; — процесс профилирования в редакторе отключает сжатие вершин (Vertex Compression); — при выполнении приложения в редакторе формируется больше временных данных в памяти. Тот же GetComponent при отсутствии компонента выделит под него временную память. В итоге Unity может выбросить исключение в редакторе, не сделав это в билде.

Кто такой «Профайлер-Верификатор»? Где обучаться необычной профессии/ @Верификатор

Статистика рендера

В Unity существует функция отображения статистики рендера в режиме реального времени (окно Game). Туда включены батчи draw calls, fps, применение VRAM, число вершин и треугольников. Чтобы включить слой статистики, нажмите на кнопку Stats, которая расположена на панели окна Game. Данная статистика поможет вам анализировать батчинг и GPU-производительность на основе количества вызовов отрисовки.

Статистика в окне Game:

Если нужна более детальная статистика рендера по каждому кадру, откройте вкладку рендера в профайлере:

На картинке выше заметно, что пустая сцена имеет пять вызовов SetPass и пять вызовов отрисовки.

На что тут следует обратить внимание: — число вызовов SetPass имеет важную роль, ведь оно плохо влияет на производительность. И число данных вызовов должно быть как можно меньше; — Draw calls (вызовы отрисовки) — параметр менее важный, если приложение не зависит от производительности процессора. Связано это с тем, что вызовы отрисовки выполняются в рендеринговом потоке, запускаемом на процессоре. Для снижения зависимости от производительности процессора можно использовать многопоточный рендеринг.

Вызовы отрисовки

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

Graphics Jobs и многопоточный рендер

Graphics Jobs (Player Settings) и многопоточный рендер в большинстве случаев позитивно влияют на производительность, однако в процессе отладки и профилирования ряд показателей может быть «размытым». Если интересует более точное профилирование, вам будет полезно глянуть на оптимизацию графики в Unity.

Кадровый отладчик

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

Кадровый отладчик не показывает отдельные вызовы отрисовки, как не показывает он и разницу между ними. Зато он показывает сам процесс построения кадра. Лишь нативные GPU-профайлеры дают подробную информацию о вызовах отрисовки (как правило, привязанную ко времени). Ещё отладчик будет полезен при отладке пайплайна и батчинга (в особенности, если вы работаете с Unity UI). Впрочем, подробную информацию лучше смотреть в документации.

Профайлер памяти

Вот пример проекта, где демонстрируется применение профайлера памяти. Кстати, по нему тоже есть прекрасная документация. Ниже представлен снимок с профайлера памяти:

Этот инструмент отслеживает память, которая выделена подсистемами Unity и пользовательскими скриптами (до версии 2017.3). При этом профайлер не способен отслеживать выделение памяти из сторонних инструментов. Зато, начиная с Unity 2017.3, профайлер поддерживает отслеживание управляемых объектов в среде выполнения Mono scripting.

Подробнее о профайлере смотрите в официальной документации. Кстати, есть и толковое видео.

Источник: myunity.dev

Как ускорить 1С – Анализ запросов с помощью SQL Profiler

Зачастую в работе возникает ситуация, когда запрос в 1С по каким-то причинам работает медленно, но анализ текста запроса не говорит нам о каких-либо проблемах.

В таком случае приходится изучать эту проблему на более низком уровне. Для этого нам нужно посмотреть текcт SQL-запроса и план запроса. Для этого можно использовать SQL Profiler.

SQL Profiler – предназначение

SQL Profiler – это программа, входящая в MS SQL Server, которая предназначена для просмотра всех событий, которые происходят в SQL-сервере. Иначе говоря, она нужна для записи трассировки.

В каких случаях данный инструмент может быть полезен 1С программисту? Прежде всего, можно получить текст запроса на языке SQL и посмотреть его план. Это также можно сделать и в технологическом журнале (ТЖ), но план запроса в ТЖ получается не таким удобным и требует наличия некоторых навыков и умений. К тому же в профайлере можно посмотреть не только текстовый, но и графический план выполнения запроса, что является более удобным.

Также профайлер позволяет узнать:

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

Анализ запросов с помощью SQL Profiler

Зачастую Profiler применяется именно для анализа запросов. И при этом нужно анализировать не все исполняемые запросы, а то, как определенный запрос на языке 1С транслируется в SQL, и обращать внимание на его план выполнения.

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

Для отслеживания запроса в трассировке выполняем следующие шаги:

1. Запускаем SQL Profiler: Пуск — Все программы — Microsoft SQL Server 2008 R2 — Средства обеспечения производительности — SQLProfiler.

2. Создаем новую трассировку: Файл – Создать трассировку (Ctrl+N).

3. Указываем сервер СУБД, на котором находится наша база данных и нажимаем Соединить:

Нам ничто не мешает выполнять трассировку сервера СУБД, находящегося на любом другом компьютере.

4. В появившемся окне Свойства трассировки переключаемся на закладку Выбор событий:

5. Далее нужно указать события и их свойства, которые мы хотим видеть в трассировке.

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

Описание этих событий:

• ShowplanStatisticsProfile– текстовый план выполнения запроса
• ShowplanXMLStatisticsProfile– графический план выполнения запроса
• RPC:Completed– текст запроса, если он выполняется как процедура (если выполняется запрос 1С с параметрами)
• SQL:BatchCompleted– текст запроса, если он выполняется как обычный запрос (если выполнялся запрос 1С без параметров)

6. На этом этапе необходима настройка фильтра для выбранных событий. Если фильтр не установлен, то мы будем видеть запросы для всех БД, расположенных на данном сервере СУБД. По кнопке Фильтры столбцов устанавливаем фильтр по имени базы данных:

Теперь мы видим в трассировке только запросы к БД «TestBase_8_2».

Также можно поставить фильтр и по другим полям, наиболее интересные из них:

• Duration (длительность)
• TextData (обычно это текст запроса)
• RowCounts (количество строк, возвращаемых запросом)

Допустим, нам необходимо «отловить» все запросы к таблице «_InfoRg4312» длительностью более 3-х секунд в базе данных «TestBase_8_2». Для этого необходимо:

a) Установить фильтр по базе данных (см. выше)
b) Установить фильтр по длительности (устанавливается в миллисекундах):

c) Установить фильтр по тексту запроса:

Для задания фильтра по тексту запроса используем маску. В случае необходимости отслеживать запросы, которые обращаются к нескольким таблицам, создается несколько элементов в разделе «Похоже на». Наложенные условия фильтров работают совместно.

7. Теперь запускаем трассировку с помощью кнопки Запустить в окне Свойства трассировки и наблюдаем события, попадающие под установленные фильтры, отображение которых было настроено.

Кнопки командной панели служат для управления трассировкой:

• Ластик – очищает окно трассировки
• Пуск – запускает трассировку
• Пауза – ставит трассировку на паузу, при нажатии на Пуск трассировка возобновляется
• Стоп – останавливает трассировку

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

9. Запустим на выполнение запрос в консоли запросов 1С и посмотрим, как он отразится в профайлере:

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

10. Свойства событий дают возможность оценить:

• сколько секунд выполнялся запрос (Duration)
• сколько было логических чтений (Reads)
• сколько строк запрос вернул в результате (RowCounts) и т.д.

В нашем случае запрос выполнялся 2 миллисекунды, сделал 4 логических чтения и вернул 1 строку.

11. Если взглянуть на одно событие выше, то можно увидеть план запроса в графическом виде:

Из плана видно, что поиск осуществляется по индексу по цене, этот план нельзя назвать идеальным, так как индекс не является покрывающим, поля код и наименование получаются с помощью KeyLookup, что отнимает 50% времени.

Используя контекстное меню, полученный графический план запроса возможно сохранить в отдельный файл с расширением *.SQLPlan и открыть его в профайлере на другом компьютере или с помощью программы SQL Sentry Plan Explorer, которая является более продвинутой.

12. Если подняться еще выше, то мы увидим тот же план запроса, но уже в текстовом виде. Именно этот план отображается в ТЖ, ЦУП и прочих средствах контроля производительности 1С.

13. Через меню Файл – Сохранить как можно сохранить всю трассировку в различные форматы:

• В формат самого профайлера, то есть с расширением *.trc
• В формат xml
• Сделать из трассировки шаблон (См. следующий пункт)
• Cохранить полученную трассировку в виде таблицы базы данных. Это весьма удобный способ, когда, к примеру, нужно найти самый медленный запрос в трассировке или отфильтровать запросы по какому-либо параметру.

Используем меню Файл – Сохранить как – Таблица трассировки – Выбираем сервер СУБД и подключаемся к нему.

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

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

Также нужно помнить, что Duration сохраняется в таблицу в миллионных долях секунды, и при выводе результата нужно переводить значение в миллисекунды. Также в таблице присутствует столбец RowNumber, показывающий номер данной строки в трассировке.

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

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

Для создания шаблона используем меню Файл – Шаблоны – Новый шаблон:

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

На второй закладке делаем выбор нужных событий и осуществляем настройку фильтров (как было показано выше).

Дополнительно рекомендуется выполнить настройку порядка столбцов в трассировке, что экономит время при последующем анализе запросов. Удобным представляется следующий порядок:

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

Бурмистров Андрей

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

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

Содержание курса и форма заказа: https://курсы-по-1с.рф/1c-v8/optimization/

35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.

Вы пишете: “По поведению трассировки видно, что запросов в итоге получилось несколько, и только один из них нам интересен. Остальные запросы – служебные.” А как узнать, какой из них наш основной запрос?

Андрей Бурмистров

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

Ярослав Бессчетнов

Добрый день. Подскажите, пожалуйста, почему в Profiler отображается не название используемого индекса (_Reference7_ByFieldFld109), а его номер (_Reference7_9)?
В примерах: Index Seek(OBJECT:([demo].[dbo].[_Reference7].[_Reference7_ByFieldFld109] AS [T1])
У меня: Index Seek(OBJECT:([demo].[dbo].[_Reference7].[_Reference7_9] AS [T1])
И только в обработке “Просмотр метаданных” я по номеру 9 нахожу этот индекс в списке и понимаю, что на самом деле поиск шел по индексу _Reference7_ByFieldFld109?

Андрей Бурмистров

Начиная с одной из версий платформы, индексы в СУБД стали именоваться по другому принципу “ИмяТаблицы_ПорядковыйНомер”, ранее нумерация была связана с названием и типом полей из которых индекс состоит. Изменение в платформе произошло относительно недавно, с этим и связано такое отличие.

Ярослав Бессчетнов

Андрей, правильно я понимаю, что порядковый номер индекса совпадает с порядком в обработке “Структура хранения метаданных” и начинается не с 0, а с 1?

Андрей Бурмистров

Имя индекса отображается одинаково и в MS SQL и в обработке структура хранения метаданных и начинается с 1.

Источник: xn—-1-bedvffifm4g.xn--p1ai

SQL Profiler Express — использование инструмента для решения проблем по SQL запросам

В этой статье мы разберем как работать с таким полезным инструментом как SQL Server Profiler. C помощью этого инструмента вы научитесь мониторить все запросы, которые выполняются на базе SQL Server.

Что такой SQL Server Profiler Express

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

Как работать с SQL Profiler Express

Скачать его можно здесь .

Выглядит окно программы следующим образом:

В верхней части программы указываем имя сервера, Windows или SQL Server авторизацию, если SQL server — то имя пользователя и пароль для входа. После чего нажимаем Start trace. После этого любой запрос, сделанный к этом серверу будет отображен в списке.

если будет ошибка “Нет разрешения на запуск SP_TRACE_CREATE”, то нужно дать юзеру базы разрешение “ ALTER TRACE ”:

use master GRANT ALTER TRACE TO user1;

Описание колонок

Text data: текст перехваченного запроса

Login name: имя пользователя, который выполнял запрос

CPU: количество процессорного времени (в миллисекундах)

Reads: количество чтений с диска, выполненных сервером

Writes: количество записей на диск, выполненных сервером

Duration: продолжительность запроса (в миллисекундах)

SPID: идентификатор процесса сервера

Start time, End time — время начала и конца запроса

Анализ

В первую очередь надо искать самые большие по продолжительности запросы — именно они чаще всего бесполезно занимают потоки веб сервера, которые не могут завершить http запрос пока не получат результаты от базы. Затем смотреть, какие запросы занимают много процессорного времени — такие процессы могут напрасно расходовать ресурсы системы.

Что делать после

В первую очередь проверить, что не выполняется лишних дополнительных запросов — т.е. вся информация из таблицы читается одним запросом за раз.

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

1. Скопировать нужный запрос в SQL Server Management Studio
2. Выбрать Запрос — Показать предполагаемый план выполнения

После чего будет показан план запроса. Выглядит это так.

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

В рамках платформы есть встроенные средства для выявления проблемных запросов. Смотрите статью Диагностика сайта на Falcon Space.

Источник: falconspace.ru

Используем профайлер в Unity: практические советы

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

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

Если мы хотим активировать профайлер в приложении, следует в окне Build Settings (File→Build Settings) включить параметры Autoconnect Profiler и Development Build. После запуска приложения профайлер станет запускаться автоматически. Вдобавок к этому, вы можете подключить профайлер в Profiler Controls, используя выпадающий список в редакторе.

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

Выполняем профилирование в редакторе

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

Deep Profile

Это режим, в котором происходит отдельная запись вызовов каждого метода, в результате чего обеспечивается чёткое представление дерева методов. Тут следует вспомнить, что, начиная с Unity версии 2017.3, режим Deep Profile работает не только в редакторе, но также на Android и Desktop с применением бэкенда Mono.

Чтобы включить режим Deep Profile, задействуйте такой аргумент командной строки, как -deepprofiling . А если хотите включить данный режим на Android, вам подойдёт аргумент adb .

~$ adb shell am start -n com.company.game/com.unity3d.player.UnityPlayerActivity -e ‘unity’ ‘-deepprofiling’

Профилируем память в редакторе

Процесс профилирования памяти в редакторе полезен для понимания общей модели памяти, однако малополезен для фактических показателей конкретных устройств.

Здесь нужно отметить следующее: — во время выполнения у каждого меша флаг read/write установлен вне зависимости от значения Read/Write Enabled в настройках импорта ассета. В результате удваивается память мешей, отображаемая в профайлере; — процесс профилирования в редакторе отключает сжатие вершин (Vertex Compression); — при выполнении приложения в редакторе формируется больше временных данных в памяти. Тот же GetComponent при отсутствии компонента выделит под него временную память. В итоге Unity может выбросить исключение в редакторе, не сделав это в билде.

Статистика рендера

В Unity существует функция отображения статистики рендера в режиме реального времени (окно Game). Туда включены батчи draw calls, fps, применение VRAM, число вершин и треугольников. Чтобы включить слой статистики, нажмите на кнопку Stats, которая расположена на панели окна Game. Данная статистика поможет вам анализировать батчинг и GPU-производительность на основе количества вызовов отрисовки.

Статистика в окне Game:

Если нужна более детальная статистика рендера по каждому кадру, откройте вкладку рендера в профайлере:

На картинке выше заметно, что пустая сцена имеет пять вызовов SetPass и пять вызовов отрисовки.

На что тут следует обратить внимание: — число вызовов SetPass имеет важную роль, ведь оно плохо влияет на производительность. И число данных вызовов должно быть как можно меньше; — Draw calls (вызовы отрисовки) — параметр менее важный, если приложение не зависит от производительности процессора. Связано это с тем, что вызовы отрисовки выполняются в рендеринговом потоке, запускаемом на процессоре. Для снижения зависимости от производительности процессора можно использовать многопоточный рендеринг.

Вызовы отрисовки

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

Graphics Jobs и многопоточный рендер

Graphics Jobs (Player Settings) и многопоточный рендер в большинстве случаев позитивно влияют на производительность, однако в процессе отладки и профилирования ряд показателей может быть «размытым». Если интересует более точное профилирование, вам будет полезно глянуть на оптимизацию графики в Unity.

Кадровый отладчик

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

Кадровый отладчик не показывает отдельные вызовы отрисовки, как не показывает он и разницу между ними. Зато он показывает сам процесс построения кадра. Лишь нативные GPU-профайлеры дают подробную информацию о вызовах отрисовки (как правило, привязанную ко времени). Ещё отладчик будет полезен при отладке пайплайна и батчинга (в особенности, если вы работаете с Unity UI). Впрочем, подробную информацию лучше смотреть в документации.

Профайлер памяти

Вот пример проекта, где демонстрируется применение профайлера памяти. Кстати, по нему тоже есть прекрасная документация. Ниже представлен снимок с профайлера памяти:

Этот инструмент отслеживает память, которая выделена подсистемами Unity и пользовательскими скриптами (до версии 2017.3). При этом профайлер не способен отслеживать выделение памяти из сторонних инструментов. Зато, начиная с Unity 2017.3, профайлер поддерживает отслеживание управляемых объектов в среде выполнения Mono scripting.

Подробнее о профайлере смотрите в официальной документации. Кстати, есть и толковое видео.

Источник: otus.ru

Профайлинг в программировании (на примере языка C)

Профайлинг (Profiling) представляет собой автоматизированный анализ того, сколько времени тратится на выполнение различных частей вашей программы. Хороший профиль будет давать детальное описание количества вызовов и количества времени CPU, занятого каждой функцией. Это плоский профиль. А очень хороший профиль способен на большее: он анализирует последовательности вызовов и сообщает, какие функции вызывают другие функции (и какие именно) чаще всего и, опять же, время и количество этих вызовов. Такой профиль называется графическим.

Профили почти исключительно определяют время CPU и количество вызовов, но они не в состоянии определять время ввода/вывода, задержки сети и решать возможные проблемы. Однако во многих случаях эти задержки могут быть выведены из того, как часто вызываемая библиотечная функция ассоциируется с проблемами времени в вашей задаче. Например, частые обращения к функции fread могут говорить о том, что ваша программа связана с вводом/выводом, а время работы CPU — не проблема. Уделите особое внимание анализу этих факторов тогда, когда общее время CPU, указываемое профилем, является только долей от наблюдаемого предельного времени, затрачиваемого вашей программой, поскольку это указывает на то, что узкое место программы находится в некоторой другой подсистеме и связано, возможно, с памятью, диском или активностью сети.

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

Примечание: Небольшое дополнение: для инструментов С-профайлинга нет стандарта ANSI/ISO, и в настоящее время для каждой среды программирования нужно иметь свои собственные инструменты для выполнения профиля в собственном конкретном формате этой среды. В этой главе будут использоваться примеры свойств prof и gprof из среды программирования UNIX, но это только примеры. Вы можете полистать документацию по вашей собственной среде программирования, чтобы определить, какие инструменты профайлинга вам доступны. Представленные здесь абстрактные концепции должны применяться для всех сред, в которых выполняется профайлинг, хотя детали будут, конечно, существенно различаться в зависимости от конкретной среды программирования.

Плоский профиль

Это наиболее общий формат профиля, который интерпретируется проще всего. Каждая функция хронометрируется, основываясь на времени работы CPU, и наиболее медлительные функции перечисляются в порядке убывания затрачиваемого ими времени. Следующий профиль был снят с программы, которая читает в файле, а затем сортирует данные с использованием метода пузырьковой сортировки и сравнения строк с учетом регистра:

А теперь подробнее рассмотрим содержащиеся в колонках величины для этого конкретного примера:

1. В первой колонке представлено время, затраченное на выполнение каждой функции, в процентах от общего времени выполнения программы; сортировка порядка следования функций в списке проводилась по этой колонке. Как видно, самая верхняя функция больше других нуждается в оптимизации и может дать существенный выигрыш по общему времени выполнения программы.
2. Накопленное время в секундах — показано суммарное время, затрачиваемое всеми функциями до рассматриваемой позиции. Заметим, что это общее время на все обращения к конкретной функции, а не время одного ее вызова.
3. Индивидуальное время показывает, сколько секунд занимает работа каждой функции. Это также общее время на все вызовы функции, а не время одного вызова.
4. Четвертая колонка — это просто количество вызовов каждой конкретной функции.
5. Собственное время одного вызова — это время в миллисекундах, затрачиваемое на одно обращение к каждой функции. Вы можете надеяться на то, что ваш профиль будет немного более расторопным по времени и будет измеряться не в миллисекундах, как в нашем примере, а в микросекундах!
6. Общее время одного вызова — расширение данных предыдущей колонки, которое включает время, затрачиваемое в подпрограммах.
7. Последняя колонка содержит название каждой исследуемой функции.

Теперь остановимся на нескольких важных моментах. Оригинальная программа имеет только три явно определенные функции — compare, bubblesort и main. Но построенный профиль показывает много других, якобы не относящихся к делу функций. Первая из них, которую мы можем не принимать в расчет, — это функция internal_mcount, которая фактически является артефактом (Artifact — искусственный объект. — Прим. пер.) процесса измерений.

Некоторые другие функции являются библиотечными. Заметьте, что обращение к функциям fread или twrite или к другой стандартной библиотечной функции ввода/вывода сразу говорит о том, что скорость работы вашей программы определяется в первую очередь скоростью ввода/вывода, а не скоростью вычислений, и потому должна быть оптимизирована в соответствии именно с этим критерием.

Полученный профиль свидетельствует также о том, что нужно было бы оптимизировать и функцию compare. В частности, мы должны обратить внимание на вызовы функций strlen и toupper, количество которых можно было бы сократить либо вообще отказаться от них.

А вот о чем нам не говорит профиль, так это о том, что фактическая проблема, связанная с этой программой, состоит в использовании функции bubblesort (поскольку это достаточно хилый алгоритм сортировки), а также о том, какие вызовы strlen или toupper действительно нужны, поскольку эти функции, в принципе, могут быть вызваны из самых разных мест в программе.

Графические профили

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

Ниже приведен отрывок из некоего графического профиля. (В интересах экономии места некоторые несущественные части оригинального профиля были опущены. Оригинальный отчет имел длину в 15 страниц.)

Показанный в этой таблице профиль содержит три раздела, в которых подытожено время выполнения и подсчитано количество вызовов функций main, bubblesort и compare. Каждый раздел идентифицирован именем функции с отступом в колонке «Имя» (колонка 6). Внутри каждого раздела вызванные подпрограммы перечисляются ниже строки функции, а вызывающие — выше строки в порядке убывания затраченного на их выполнение времени.

Смысл отдельных колонок в этом профиле следующий:

1. Первая колонка представляет некоторый числовой индекс и не несет значительной информации.
2. Время в % показывает общее количество времени, затраченного данной функцией и всеми вызывавшими ее функциями (а также функциями, которые они вызывают повторно, и т.п.). Поскольку каждая из них первоначально вызывалась из main, она появляется одной из первых вверху каждого раздела отчета, как здесь показано, но это не означает, что именно эти функции должны быть целью оптимизации.
3. Собственное (время) — общее количество секунд, затраченных на выполнение этой функции, не включает время, затраченное вызываемыми ею подпрограммами. Другими словами, хотя профиль указывает, что main затрачивает 46.2% времени в работе программы, фактически main затратила 0 секунд, а остальное время было затрачено подпрограммами, которые вызвала main.
4. По убыванию — общее количество секунд, затраченных в функциях, вызванных данной функцией.
5. Вызвана/Итого — отношение количества вызовов данной функции из конкретной родительской функции к количеству вызовов ею дочерних функций.
6. Имя — названия функций, как они упоминаются в запросах. Функции, которые появляются выше записанной с отступом функции, являются вызывающими, те же, которые появляются ниже ее, — это вызываемые функции.

Графический профиль дает нам пищу для размышлений о.том, какие функции следовало бы оптимизировать. В отличие от плоского профиля, на графическом профиле проявляется факт чрезмерно большого количества обращений bubblesort к функции compare, хотя самой функцией bubblesort расходуется совсем не много времени.

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

Другие методы профайлинга

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

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

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

Похожие статьи:

• Стили расстановки отступов при программировании на языке C
• Типичные фразочки программиста
• Создание баз данных в Microsoft SQL Server 2005 (В среде MVS)
• Об объектно–ориентированном программировании
• Законы настоящего программиста

Добавлено: 14.09.2011 | —>Просмотров : 9474 | —>Рейтинг : 0.0 / 0 |
—>Теги : профайлинг, язык Си, си, программирование

Источник: fevt.ru