Что такое профилирование в программировании

Профилирование (информатика)

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

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

Это часто используется, чтобы определить, как долго выполняются определенные части программы, как часто они выполняются, или генерировать граф вызовов (Call Graph). Обычно эта информация используется, чтобы идентифицировать те участки программы, которые работают больше всего. Эти трудоёмкие участки могут быть оптимизированы, чтобы выполняться быстрее.

Также выделяют анализ покрытия (Code Coverage) — процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

См. также

Ссылки

Профилирование в программировании: какой профилировщик выбрать

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

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

Сегодня нас интересует, что такое профилировщик в программировании. Описание работы таких программ в других сферах оставим для следующих статей.

Профилировщик в программировании — что это?

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

Программы-профилировщики

1. «gprof». Многоплатформенный и многофункциональный профилировщик.
2. «VТune». Программный продукт компании Intel на платной основе.
3. «Single Event API». Программный продукт компании Intel на бесплатной основе.
4. «CodeAnalyst». Универсальный профилировщик компании AMD.
5. «AQtime». Профилировщик для операционной системы Windows.
6. «Instruments». Профилировщик для операционной системы MacOS.
7. «Perf». Профилировщик для операционной системы Linux.
8. «dotMemory». Профилировщик памяти разных систем.

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Общие сведения о профилировании

Профилировщик — это инструмент, который наблюдает за выполнением другого приложения. Профилировщик среды CLR — это библиотека DLL, содержащая функции, которые получают сообщения из среды CLR и отправляют сообщения в среду CLR с помощью API профилирования. Библиотека DLL профилировщика загружается средой CLR во время выполнения.

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

Для профилирования приложения среды CLR требуется дополнительная поддержка по сравнению с профилированием стандартно скомпилированного машинного кода. Это объясняется тем, что в среде CLR вводятся такие понятия, как домены приложений, сборка мусора, обработка управляемых исключений, JIT-компиляция кода (преобразование кода MSIL в машинный код) и другие аналогичные возможности. Механизмы традиционного профилирования не могут обнаруживать эти возможности или предоставлять полезные сведения о них. API профилирования эффективно предоставляет эти отсутствующие сведения с минимальным влиянием на производительность среды CLR и профилируемого приложения.

JIT-компиляция во время выполнения обеспечивает прекрасные возможности для профилирования. API профилирования позволяет профилировщику вносить изменения потока кода MSIL в памяти для подпрограммы перед ее JIT-компиляцией. Таким образом, профилировщик может динамически добавлять код инструментирования в определенные подпрограммы, требующие более глубокого анализа. Хотя такой подход возможен в обычных сценариях, его гораздо проще реализовать для среды CLR с помощью API профилирования.

API профилирования

Как правило, API профилирования используется для написания профилировщика кода, который является программой, которая отслеживает выполнение управляемого приложения.

API профилирования используется библиотекой DLL профилировщика, которая загружается в один процесс с профилируемым приложением. Библиотека DLL профилировщика реализует интерфейс обратного вызова (ICorProfilerCallback в платформа .NET Framework версии 1.0 и 1.1, ICorProfilerCallback2 в версии 2.0 и более поздних). Среда CLR вызывает методы этого интерфейса для уведомления профилировщика о событиях в процессе профилирования. Профилировщик может вызывать обратно в среду выполнения, используя методы в интерфейсах ICorProfilerInfo и ICorProfilerInfo2 для получения сведений о состоянии профилированного приложения.

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

На следующем рисунке показано, как библиотека DLL профилировщика взаимодействует с профилируемым приложением и средой CLR.

Интерфейсы уведомлений

ICorProfilerCallback и ICorProfilerCallback2 можно считать интерфейсами уведомлений. Эти интерфейсы состоят из таких методов, как ClassLoadStarted, ClassLoadFinished и JITCompilationStarted. Каждый раз, когда среда CLR загружает или выгружает класс, компилирует функцию и т. д., она вызывает соответствующий метод в интерфейсе ICorProfilerCallback или ICorProfilerCallback2 профилировщика.

Например, профилировщик может измерять производительность кода с помощью двух функций уведомлений: FunctionEnter2 и FunctionLeave2. Он просто устанавливает метки времени для каждого уведомления, собирает результаты и выводит список, в котором указывается, на какие функции было затрачено больше ресурсов ЦП или физического времени во время выполнения приложения.

Интерфейсы для извлечения сведений

Другими интерфейсами main, участвующими в профилировании, являются ICorProfilerInfo и ICorProfilerInfo2. Профилировщик вызывает эти интерфейсы по мере необходимости для получения дополнительных сведений, помогающих выполнить анализ. Например, всякий раз, когда среда CLR вызывает функцию FunctionEnter2 , она предоставляет идентификатор функции. Профилировщик может получить дополнительные сведения об этой функции, вызвав метод ICorProfilerInfo2::GetFunctionInfo2 для обнаружения родительского класса функции, ее имени и т. д.

Поддерживаемые компоненты

API профилирования предоставляет сведения о различных событиях и действиях, которые происходят в среде CLR. Эти сведения можно использовать для мониторинга внутренней работы процессов и анализа производительности приложения .NET Framework.

API профилирования извлекает сведения о следующих действиях и событиях, происходящих в среде CLR.

• События запуска и завершения работы среды CLR.
• События создания и завершения работы домена приложения.
• События загрузки и выгрузки сборки.
• События загрузки и выгрузки модуля.
• События создания и удаления таблицы VTable COM.
• События JIT-компиляции и пошагового выполнения кода.
• События загрузки и выгрузки класса.
• События создания и удаления потока.
• События входа и выхода функции.
• Исключения.
• Переходы между выполнением управляемого и неуправляемого кода.
• Переходы между различными контекстами среды выполнения.
• Сведения о приостановках среды выполнения.
• Сведения о действиях сборки мусора и кучи в памяти времени выполнения.

API профилирования можно вызывать из любого (неуправляемого) языка, совместимого с COM.

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

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

Неподдерживаемые функциональные возможности

API профилирования не поддерживает следующие функциональные возможности.

• Неуправляемый код, который необходимо профилировать с помощью стандартных методов Win32. Однако профилировщик среды CLR включает события переходов для определения границ между управляемым и неуправляемым кодом.
• Самоизменяющиеся приложения, которые изменяют собственный код приложения, которые изменяют собственный код, например в целях аспектно-ориентированного программирования.
• Проверка привязок, поскольку API профилирования не предоставляет эти сведения. Среда CLR предоставляет существенную поддержку для проверки границ всего управляемого кода.
• Удаленное профилирование, которое не поддерживается по следующим причинам.
  • Удаленное профилирование увеличивает время выполнения. При использовании интерфейсов профилирования необходимо минимизировать время выполнения, чтобы оно не слишком сильно сказывалось на результатах профилирования. Это особенно важно при мониторинге производительности. Тем не менее удаленное профилирование не является ограничением при использовании интерфейсов профилирования для мониторинга использования памяти или для получения сведений времени выполнения о кадрах стека, объектах и т. п.
  • Профилировщик кода среды CLR должен зарегистрировать один или несколько интерфейсов обратного вызова в среде выполнения на локальном компьютере, на котором выполняется профилируемое приложение. Это ограничивает возможность создания удаленного профилировщика кода.

  Потоки уведомлений

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

  Обратите внимание, что эти обратные вызовы не сериализуются. Пользователи должны защищать свой код, путем создания потокобезопасных структур данных и путем блокировки кода профилировщика в тех случаях, когда необходимо предотвратить параллельный доступ из нескольких потоков. Таким образом, в некоторых случаях можно получить необычную последовательность обратных вызовов. Например, предположим, что управляемое приложение порождает два потока, выполняющие идентичный код. В этом случае можно получить событие ICorProfilerCallback::JITCompilationStarted для одной функции из одного потока и обратный FunctionEnter вызов из другого потока перед получением обратного вызова ICorProfilerCallback::JITCompilationFinished . В этом случае пользователь получит обратный вызов FunctionEnter для функции, которая могла быть не полностью JIT-скомпилирована.

  Безопасность

  Библиотека DLL профилировщика — это неуправляемая библиотека DLL, которая выполняется в рамках подсистемы выполнения среды CLR. В результате на код в библиотеке DLL профилировщика DLL не налагаются ограничения управления доступом для управляемого кода. Для библиотеки DLL профилировщика действуют только ограничения, накладываемые операционной системой на пользователя, запускающего профилируемое приложение.

  Разработчики профилировщика должны принять соответствующие меры предосторожности, чтобы избежать проблем, связанных с безопасностью. Например, во время установки библиотека DLL профилировщика должна добавляться в список управления доступом (ACL), чтобы злоумышленник не мог изменить ее.

  Объединение управляемого и неуправляемого кода в коде профилировщика

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

  Обзор API профилирования среды CLR может создать впечатление, что можно написать профилировщик, содержащий управляемые и неуправляемые компоненты, которые вызывают друг друга посредством COM-взаимодействия или непрямых вызовов.

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

  Единственное место, где профилировщик CLR может безопасно вызывать управляемый код, это текст MSIL в теле метода. Для изменения текста MSIL рекомендуется использовать методы JIT-перекомпиляции в интерфейсе ICorProfilerCallback4 .

  Кроме того, для изменения MSIL можно использовать старые методы инструментирования. Перед завершением JIT-компиляции функции профилировщик может вставлять управляемые вызовы в текст MSIL метода, а затем JIT-компиляцию (см. метод ICorProfilerInfo::GetILFunctionBody ). Этот способ можно успешно использовать для выборочного инструментирования управляемого кода или для сбора статистики и данных производительности касательно JIT.

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

  Профилирование неуправляемого кода

  API профилирования среды CLR предоставляет минимальную поддержку профилирования неуправляемого кода. Предоставляются следующие функциональные возможности.

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

  В .NET Framework версий 1.0 и 1.1 эти методы доступны через внутрипроцессное подмножество API отладки среды CLR. Они определяются в файле CorDebug.idl.

  В платформа .NET Framework 2.0 и более поздних версий для этой функции можно использовать метод ICorProfilerInfo2::D oStackSnapshot.

  Использование модели COM

  Хотя интерфейсы профилирования определяются как COM-интерфейсы, среда CLR в действительности не инициализирует модель COM для использования этих интерфейсов. Причина заключается в том, чтобы избежать необходимости задавать модель потоков с помощью функции CoInitialize до того, как управляемое приложение будет иметь возможность указать требуемую модель потоков. Аналогично, сам профилировщик не должен вызывать CoInitialize , поскольку он может выбрать потоковую модель, несовместимую с профилируемым приложением, что может привести к сбою приложения.

  Стеки вызовов

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

  Моментальный снимок стека

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

  Дополнительные сведения о том, как запрограммировать профилировщик для обхода управляемых стеков, см. в разделе Метод ICorProfilerInfo2::D oStackSnapshot в этом наборе документации и Профилировщик стека Walk в платформа .NET Framework 2.0: Основные и более подробные сведения.

  Теневой стек

  Слишком частое использование метода моментального снимка может быстро создавать проблемы производительности. Если вы хотите часто выполнять трассировки стека, профилировщик должен создать теневой стек с помощью обратных вызовов исключений FunctionEnter2, FunctionLeave2, FunctionTailcall2 и ICorProfilerCallback2 . Теневой стек всегда является текущим, и его можно быстро скопировать в хранилище каждый раз, когда требуется моментальный снимок стека.

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

  Обратные вызовы и глубина стека вызовов

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

  См. также

  Заголовок	Описание
  Установка профилирующей среды	В этом разделе объясняется, как можно инициализировать профилировщик, установить уведомления о событиях и профилировать службу Windows.
  Профилирующие интерфейсы	В этом разделе описываются неуправляемые интерфейсы, которые использует API профилирования.
  Глобальные статические функции профилирования	В этом разделе описываются неуправляемые глобальные статистические функции, которые использует API профилирования.
  Перечисления профилирования	В этом разделе описываются неуправляемые перечисления, которые использует API профилирования.
  Структуры профилирования	В этом разделе описываются неуправляемые структуры, которые использует API профилирования.

  Совместная работа с нами на GitHub

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

  Профилирование кода

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

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

  Многие программы, в особенности индикаторы, осуществляют какие-либо расчеты только при приходе нового тика (OnTick, OnCalculate). Таким образом, для оценки производительности приходится ждать поступления новых тиков в режиме реального времени. Используя профилирование на исторических данных, вы можете сразу давать нужную нагрузку и проверять работу программ даже в выходные дни, когда рынки закрыты.

  Как происходит профилирование

  Для профилирования используется метод «Sampling». Профилировщик делает паузы в работе MQL-программы (~1000 раз в секунду) и собирает статистику того, сколько раз пауза пришлась на тот или иной участок кода. В том числе анализируются стеки вызовов, чтобы определить «вклад» каждой функции в общее время работы кода. В конце профилирования вы получаете информацию о том, сколько раз была выполнена пауза и сколько раз каждая из функций оказывалась в стеке вызовов:

  • Общая активность ЦП [единица измерения, %] — общее количество «появления» функции в стеке вызовов.
  • Собственная активность ЦП [единица измерения, %] — количество «пауз», которые произошли непосредственно внутри указанной функции. Этот счетчик наиболее важен для определения «узких» мест, поскольку по статистике остановка чаще происходит в тех участках программы, которые требуют большего процессорного времени.

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

  Настройки профилирования

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

  

  Здесь же можно включить или отключить инлайнинг (встраивание) функций при компиляции. При инлайнинге код функций помещается непосредственно в место их вызова, что позволяет добиться существенного ускорения при работе программы. Однако это затрудняет профилирование функций. Чтобы получить отчет по «чистым» функциям, вы можете отключить инлайнинг.

  Опция отключает только явный инлайнинг. Функции, неявно сгенерированные компилятором, могут остаться. В отчете они будут отображаться с префиксом [inlined].

  Чтобы увеличить объем детализации отчета о профилировании, можно отключать режим оптимизации кода. Без оптимизации скорость кода может упасть кратно, но взамен можно увидеть более обширное покрытие кода. При использовании учитывайте, что узкие места кода будут неточными.

  Возможность управления оптимизацией кода есть также в настройках проектов.

  • Если в проекте оптимизация отключена, то новая опция игнорируется — для профилировки оптимизация всегда выключена (в том числе инлайнинг).
  • Если в проекте оптимизация включена, то при компиляции под профилировку новая опция будет учитываться.

  Запуск профилирования #

  Откройте файл исходного кода программы (MQ4 или MQ5). В меню «Отладка» или на панели инструментов «Стандартная» нажмите » Начать профилирование на реальных данных» или » Начать профилирование на исторических данных».

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

  

  • По умолчанию, приложение запускается на графике EURUSD H1. Для запуска на другом символе и периоде, укажите их на вкладке «Отладка» в настройках MetaEditor.
  • При профилировании на истории всегда используется невизуальный режим тестера. Визуальный режим практически не имеет смысла, поскольку основные ресурсы тратятся на отрисовку, а не расчеты внутри MQL-программы

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

  Далее остановите профилирование: удалите программу с графика или нажмите » Завершить профилирование» меню «Отладка» или на панели инструментов «Стандартная».

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

  Просмотр результатов профилирования

  После завершения профилирования его результаты будут открыты во вкладке «Профилировщик» окна «Инструменты». Также для наглядности результаты отображаются непосредственно в коде — путем подсветки строк с функциями. Чем ярче цвет подсветки, тем больше времени потребовалось для выполнения функции. Так вы можете быстро визуально оценить наиболее узкие места программы.

  Отчет профилирования представлен в виде функций или строк программы, для каждой из которых доступно два показателя:

  • Общая активность ЦП [единица измерения, %] — общее количество «появления» функции в стеке вызовов.
  • Собственная активность ЦП [единица измерения, %] — количество «пауз», которые произошли непосредственно внутри указанной функции. Этот счетчик наиболее важен для определения «узких» мест, поскольку по статистике остановка чаще происходит в тех участках программы, которые требуют большего процессорного времени.

  Для показателя выводится абсолютное количество и процент от общего количества.

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

  

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

  Для удобства различные элементы языка MQL отображаются в отчете иконками:

  • — пользовательская функция.
  • — системная функция.
  • — функция обработки событий (On*).
  • — метод класса.
  • — защищенный метод класса.

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

  • @global_initializations — информация по инициализации всех глобальных переменных.
  • @global_deinitializations — информация по деинициализации всех глобальных переменных.

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

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

  Контекстное меню #

  В контекстном меню доступны следующие команды:

  • Открыть — перейти к строке или функции в файле исходного кода. Это же действие можно выполнить двойным кликом мышью или нажатием Enter.
  • Развернуть все — развернуть все свернутые функции.
  • Свернуть все — свернуть все развернутые функции.
  • Функции по строкам — перейти в режим просмотра результатов профилирования по строкам.
  • Функции по вызовам — перейти в режим просмотра результатов профилирования по вызовам.
  • Экспорт — экспортировать результаты профилирования в формате Open XML (MS Office Excel), HTML (Internet Explorer) или CSV (текстовый файл).
  • Авторазмер — включить/выключить автоматическую установку размеров полей. Это же действие выполняется клавишей «A».
  • Сетка — включить/выключить сетку, разделяющую поля. Это же действие выполняется клавишей «G».
  Похожие публикации:

  1. Как в линуксе посмотреть сведения о системе
  2. Как включить диктовку на айфоне в ватсапе
  3. Как ворд 2003 перевести в пдф
  4. Как вставить картинку пнг в презентацию