При оптимизации кода или поиске "узких мест" часто возникает потребность отследить хронологию выполнения алгоритма. Разберем частый вопрос разработчиков: можно ли в конфигураторе 1С отсортировать результат инструмента "Замер производительности" так, чтобы ранее запущенный код находился выше, а более поздний — ниже. Выясним причину такого поведения системы и рассмотрим эффективные способы решения задачи.
Сразу ответим на главный вопрос: штатными средствами отсортировать окно замера по хронологии запуска невозможно. Проанализируем, почему так происходит.
Стандартный механизм в конфигураторе не предназначен для полноценной трассировки (отслеживания пошаговой хронологии). Платформа работает по принципу агрегации: она суммирует количество вызовов и общее время, затраченное на каждую конкретную строку модуля. При этом система не записывает в файл замера точную временную метку старта каждой отдельной операции. Именно поэтому специальной колонки со временем запуска просто не существует.
В качестве быстрого визуального обходного пути в окне замера можно попытаться настроить сортировку по нескольким колонкам (например, НомерСтроки и время), либо выгрузить данные в MS Excel и проанализировать их там. Однако для точного хронологического анализа этого недостаточно. Рассмотрим более профессиональные методы.
Если вам необходимо получить строгую последовательность выполнения процессов, настроим Технологический журнал платформы. ТЖ фиксирует все события последовательно в хронологическом порядке с высочайшей точностью (до микросекунд).
CALL для фиксации вызовов процедур и функций встроенного языка.DBMSSQL или DBPOSTGRS для перехвата запросов к СУБД.Context, чтобы понимать, откуда был вызван код.Полученные логи можно выстроить по времени с помощью специализированных парсеров или утилит анализа ТЖ. Это позволит в точности восстановить хронологию работы алгоритма.
Для точечного определения порядка работы алгоритма и времени выполнения конкретных участков применим ручной программный замер в коде. Посмотрим на пример реализации с помощью встроенной функции.
Обернем проблемный участок кода в переменные с фиксацией времени:
ВремяСтарта = ТекущаяУниверсальнаяДатаВМиллисекундах();
// Здесь располагается исследуемый алгоритм или вызов процедуры
ВыполнитьТяжелыйАлгоритм();
ВремяЗавершения = ТекущаяУниверсальнаяДатаВМиллисекундах();
Дельта = ВремяЗавершения - ВремяСтарта;
Сообщить("Время выполнения участка: " + Дельта + " мс");
Запись полученных временных меток можно выводить в сообщения, писать в Журнал регистрации или в текстовый файл. Это даст абсолютно точную хронологию запуска исследуемых блоков.
Если конфигурация построена на базе Библиотеки стандартных подсистем (БСП), воспользуемся встроенной подсистемой по методике APDEX. Разработчик программно расставляет метки старта и завершения ключевых операций пользователей.
В этом случае платформа 1С сохраняет точные метки времени в специализированный регистр сведений (например, ЗамерыВремени). Перейдя в этот регистр, вы сможете легко отсортировать все операции по времени запуска стандарными средствами интерфейса предприятия.
Если стоит задача понять последовательность и длительность выполнения именно SQL-запросов (как они генерируются платформой в динамике), перейдем на уровень базы данных.
Например, при использовании MS SQL Server можно запустить SQL Server Profiler и настроить перехват событий RPC:Completed и SQL:BatchCompleted. Трассировка отобразит точное время старта каждого запроса, выстраивая идеальную хронологию общения сервера 1С и СУБД.
Для разового понимания порядка прохождения кода (особенно в сложных нетиповых конфигурациях с множеством подписок на события) нет ничего лучше обычной пошаговой отладки. Остановитесь на точке прерывания и откройте окно "Стек вызовов". Оно покажет строгую иерархию и последовательность того, откуда и в каком порядке был вызван текущий модуль, что часто заменяет потребность в хронологическом замере.