Многие разработчики сталкиваются с ощущением, что с выходом новых версий платформа «1С:Предприятие 8» становится всё более «тяжелой», а скорость выполнения кода снижается. Это порождает вопросы: не замедляет ли фирма «1С» старые версии намеренно и не готовит ли нас к болезненному переходу на новую технологию, такую как «1С:Элемент»? Давайте вместе разберемся в этом вопросе, проанализируем реальные тесты производительности и выясним, где на самом деле кроются причины «тормозов».
Для оценки «чистой» скорости выполнения кода часто используют вычислительные задачи, не связанные с доступом к базе данных. Одной из таких задач является алгоритм «Решето Эратосфена» для поиска простых чисел. Исходные замеры, представленные в обсуждении, показывали удручающую картину:
1С 8.3.12 — 382 сек.1С 8.3.22 — 518 сек.1С 8.3.25 — 523 сек.Налицо замедление более чем на 35% на новых релизах. При этом альтернативные исполнители языка 1С, такие как OneScript или 1C Executer (компонент платформы «1С:Элемент»), показывают значительно лучшие результаты (28-50 секунд). А высокопроизводительные языки вроде PHP 8.3, Java или C# справляются с этой задачей за единицы секунд или даже быстрее.
Такие данные могут привести к выводу, что ядро платформы 1С деградирует. Но давайте не будем спешить и посмотрим на ситуацию глубже.
Как показали более тщательные исследования, проведенные участниками дискуссии, ключевым фактором, влияющим на скорость выполнения кода в режиме тестирования, является механизм отладки. Когда на сервере включена возможность отладки (даже если отладчик не подключен в данный момент), платформа несет существенные накладные расходы на обработку каждой строки кода.
Рассмотрим результаты повторного теста, но с одним важным условием: выполнение кода с отключенной отладкой. Этого можно добиться, установив в свойствах информационной базы флаг «Режим отладки» в значение «Запрещен» или используя программные трюки, например, выполнение всего алгоритма в одной строке.
Результаты оказались ошеломляющими:
1С 8.3.25 с включенной отладкой: ~80 секунд.1С 8.3.25 с фактически отключенной отладкой (в однострочном варианте): ~8 секунд.Разница в 10 раз! Это доказывает, что сам интерпретатор языка 1С не стал медленнее. Напротив, его производительность сопоставима с OneScript. Замедление, которое наблюдалось в первоначальном тесте, было вызвано утяжелением и усложнением именно отладочных механизмов в новых версиях платформы.
Чтобы получить объективные данные о скорости выполнения вашего кода, необходимо исключить влияние отладчика. Вот пример кода для теста, который можно адаптировать для своих задач.
// Вариант теста с ускоренным заполнением массива
&НаСервереБезКонтекста
Процедура ТестПроизводительностиНаСервере()
// _РежимОтладки - недокументированная переменная,
// которая равна Истина, если отладка разрешена для сеанса
// Ее значение можно посмотреть в отладчике
Перем _РежимОтладки;
N = 10000000;
Начало = ТекущаяУниверсальнаяДатаВМиллисекундах();
// Ускоренное заполнение массива значениями Истина
МассивФлагов = Новый Массив(N + 1, Истина);
МассивФлагов[0] = Ложь;
МассивФлагов[1] = Ложь;
Для i = 2 По N Цикл
Если МассивФлагов[i] Тогда
Для j = i*i По N Шаг i Цикл
МассивФлагов[j] = Ложь;
КонецЦикла;
КонецЕсли;
КонецЦикла;
Конец = ТекущаяУниверсальнаяДатаВМиллисекундах();
Сообщить("Время выполнения: " + (Конец - Начало) / 1000 + " сек.");
КонецПроцедуры
Вывод: при проведении замеров производительности всегда «мойте руки» — убедитесь, что отладка отключена, иначе вы будете измерять не скорость вашего алгоритма, а накладные расходы платформы на его пошаговое исполнение.
Другой важный вопрос, поднятый в теме, — это будущее платформы и возможный принудительный переход на «1С:Элемент». Давайте разберемся, что это за технологии.
Ключевые моменты:
Синтетические тесты — это полезно, но в реальной жизни производительность систем 1С определяется не скоростью выполнения цикла. Основные проблемы лежат в области взаимодействия с базой данных и неоптимальной архитектуры кода.
Проанализируем основные причины низкой производительности, которые были упомянуты в обсуждении:
Это причина №1 всех проблем. Классический антипаттерн — запрос в цикле. Вместо того чтобы получить все необходимые данные одним пакетом, разработчик в цикле обращается к базе данных за каждой порцией данных, создавая колоссальную нагрузку.
Неправильное использование динамических списков в управляемых формах — верный способ «положить» систему. Когда в тексте запроса ДС появляются сложные соединения, вложенные запросы и группировки по большим таблицам, СУБД вынуждена выполнять огромную работу для отображения каждой страницы списка. Это приводит к долгому открытию форм и мучительным задержкам при прокрутке.
Библиотека стандартных подсистем (БСП) и другие типовые механизмы предоставляют универсальный функционал, но за универсальность приходится платить производительностью. Иногда для расчета простого показателя система выполняет десятки вложенных вызовов общих функций, что может быть неоправданно медленно.
Как метко было замечено, все проблемы с производительностью сводятся к двум вещам: запросам и циклам. А если быть точнее, то к их комбинациям:
Именно оптимизация этих участков кода дает наибольший прирост производительности в реальных задачах.
Подведем черту под нашим анализом: