Почему долго открывается замер производительности при расчете больничного листа в ЗУП 3.1?

При работе с конфигурацией «Зарплата и управление персоналом 3.1» программисты часто сталкиваются с тем, что стандартные операции отладки, такие как замер производительности, выполняются крайне медленно. Ситуация, когда сам расчет документа занимает пару секунд, а таблица замера в Конфигураторе открывается минуту или дольше, является типичной для этой конфигурации. В этой статье мы разберем технические причины такого поведения системы, проанализируем влияние аппаратной части и рассмотрим способы оптимизации процесса отладки.

Анализ факторов, влияющих на скорость открытия замера

Разберем ситуацию на примере документа БольничныйЛист. Типичный замер расчета и проведения этого документа генерирует от 20 000 до 35 000 строк исполняемого кода. Скорость отображения этих данных в Конфигураторе зависит от нескольких ключевых факторов:

1. Объем метаданных и режим поддержки. Если ваша база находится в режиме «редактирование с сохранением поддержки», Конфигуратор потребляет значительно больше ресурсов. В памяти фактически удерживаются две структуры метаданных, что замедляет процесс сопоставления строк исполняемого кода с объектами дерева конфигурации при отрисовке замера.
2. Разрядность платформы. Использование 32-битной версии Конфигуратора накладывает жесткие ограничения на использование оперативной памяти (до 2–4 ГБ). При обработке больших массивов данных замера процесс может «замирать», так как система постоянно выполняет очистку памяти (Garbage Collection) или обращается к файлу подкачки.
3. Частота процессора. Процесс десериализации данных замера и построения таблицы в Конфигураторе практически не распараллеливается. Это означает, что решающее значение имеет производительность на одно ядро. Процессоры с низкой базовой частотой (например, серверные решения с множеством ядер, но низкой частотой) будут справляться с этой задачей медленнее, чем домашние или профессиональные десктопные CPU с частотой 4.5–5.0 ГГц.

Технические особенности работы профайлера 1С

Проанализируем, что происходит «под капотом» во время замера. При нажатии кнопки «Стоп» в замере производительности Конфигуратор считывает временный файл с данными (обычно это файлы с расширением .prm в папке %TEMP%). Если дисковая подсистема работает медленно (используется HDD или медленный сетевой диск), чтение этого файла станет узким местом.

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

Специфика ЗУП 3.1 и документа «Больничный лист»

Выясним, почему именно в ЗУП 3.1 замеры получаются такими «тяжелыми». Документ БольничныйЛист инициирует сложную цепочку вызовов:

• Механизмы автоматического пересчета. В ЗУП 3.1 реализован фоновый расчет среднего заработка и НДФЛ. Если замер захватывает эти процессы, количество строк кода увеличивается экспоненциально.
• Анализ регистра сведений Перерасчеты. При проведении система проверяет необходимость корректировки прошлых периодов, что влечет за собой выполнение тяжелых запросов и обработку больших массивов данных в коде.
• Использование длительных операций. Многие расчеты в ЗУП выполняются во временных хранилищах или через фоновые задания на сервере, что усложняет сбор контекста для замера.

Практические рекомендации по оптимизации процесса замера

Чтобы сократить время ожидания и сделать работу более комфортной, рассмотрим следующие шаги:

1. Точечное использование замера

Вместо того чтобы включать замер на всю операцию (открытие формы, расчет, проведение), попробуйте программно ограничивать область замера. Для этого используйте встроенную функцию УстановитьИспользованиеЗамераПроизводительности(). Это позволит отсечь лишний код инициализации формы и сосредоточиться только на проблемном участке.

Пример использования в коде:

// Отключаем общий замер, если он был включен вручную
УстановитьИспользованиеЗамераПроизводительности(Ложь);

// Выполняем подготовительные действия
Объект.ЗаполнитьДанные();

// Включаем замер только для целевой процедуры
УстановитьИспользованиеЗамераПроизводительности(Истина);
ПроведениеСервер.ВыполнитьПроведение(ЭтотОбъект);
УстановитьИспользованиеЗамераПроизводительности(Ложь);

2. Настройка аппаратного обеспечения

Для эффективной работы разработчика 1С (особенно с тяжелыми конфигурациями вроде ЗУП 3.1 или ERP) требования к «железу» должны быть следующими:

1. Диск: Исключительно NVMe SSD. Скорость случайного чтения мелких файлов критична для работы Конфигуратора и кэша метаданных.
2. Процессор: Максимальная частота на ядро (Turbo Boost от 4.5 ГГц). Количество ядер вторично.
3. Память: Минимум 32 ГБ. Это позволит операционной системе эффективно кэшировать файлы базы данных и метаданные.

3. Отключение автоматических расчетов

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

4. Очистка кэша и временных файлов

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

Рассмотренные ситуации показывают, что время открытия замера в 30-60 секунд для ЗУП 3.1 при 20-30 тысячах строк кода является условно нормальным для среднего оборудования. Однако, следуя приведенным выше рекомендациям по оптимизации кода и настройке окружения, этот показатель можно значительно улучшить, повысив эффективность разработки и отладки.