Что именно показывает замер

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

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

Как подготовить воспроизводимый сценарий

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

  1. Запишите, в какой информационной базе, разделе и форме возникает задержка.
  2. Зафиксируйте параметры операции: организацию, период отчёта, вариант настроек и приблизительный объём данных.
  3. Откройте нужную форму заранее, но не выполняйте исследуемое действие.
  4. По возможности дождитесь завершения других заметных операций в этой базе.
  5. Решите, где начинается и заканчивается проверяемый эпизод.

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

Как включить и остановить измерение

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

  1. Перейдите к форме, подготовленной для проверки.
  2. Включите замер непосредственно перед проблемным действием.
  3. Выполните только выбранную операцию и дождитесь её фактического завершения.
  4. Сразу остановите измерение, не открывая дополнительные окна и разделы.
  5. Сохраните результат тем способом, который предусмотрен вашей конфигурацией, либо сделайте снимки экрана с видимыми показателями.

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

Как читать полученную таблицу

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

Что видноКак это понимать
Большое суммарное времяНа этот участок пришлась заметная доля измеренного эпизода
Много вызововДаже короткое действие могло стать значимым из-за частого повторения
Один долгий вызовНужно изучить конкретную операцию и данные, с которыми она работала
Разные результаты повторовВозможно влияние нагрузки, кеша, фоновых процессов или состава данных

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

Как сравнивать два результата

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

Проведите несколько отдельных повторов, не превращая их в одну длинную запись. Сравните характерные результаты и отдельно отметьте необычно быстрые или медленные запуски. В рабочей базе на время могут влиять другие пользователи и регламентные операции. На локальной копии условия стабильнее, но её объём и устройство могут отличаться от рабочей системы.

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

Частые ошибки при использовании

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

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

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