При разработке сложных систем интеграции, загрузки прайс-листов или обработки больших массивов данных программисты 1С часто сталкиваются с неожиданным поведением платформы: при заполнении таблицы всего в несколько сотен тысяч строк оперативная память компьютера начинает стремительно таять, достигая нескольких гигабайт, а интерфейс «зависает» на десятки секунд. Многие ошибочно полагают, что проблема кроется в неэффективности объекта ТаблицаЗначений или ТабличнаяЧасть. Однако, как показывает практика и детальный анализ механизмов платформы, корень зла часто скрывается в особенностях работы управляемого приложения и передачи данных между клиентом и сервером.
В этой статье мы подробно проанализируем, почему 1С «ест» память, разберем влияние контекстных вызовов и выясним, как оптимизировать код так, чтобы обработка миллионов строк не приводила к аварийному завершению работы системы.
Рассмотрим стандартную ситуацию: нам нужно программно заполнить табличную часть обработки или реквизит формы типа ДанныеФормыКоллекция на сервере и отобразить результат пользователю. Проанализируем типичный, но крайне опасный код:
&НаСервере
Процедура ЗаполнитьТаблицуНаСервере()
// Преобразуем данные формы в объект для использования методов модуля объекта
ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
// Вызываем процедуру заполнения в модуле объекта
ОбработкаОбъект.ВыполнитьЗагрузкуМиллионаСтрок();
// Возвращаем измененный объект обратно в данные формы
ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");
КонецПроцедуры
Выясним причину, по которой этот код вызывает колоссальный рост потребления RAM. В момент вызова ЗначениеВРеквизитФормы платформа начинает процесс сериализации данных. В управляемом приложении данные на клиенте хранятся не в чистом виде, а в структурах ДанныеФормы. При конвертации из прикладного объекта (например, ОбработкаОбъект) в реквизит формы, каждая ячейка таблицы «обрастает» служебной информацией: признаками модифицированности, типами данных, связями с элементами управления. Накладные расходы могут увеличивать объем данных в 10–20 раз по сравнению с чистой памятью таблицы значений.
Более того, при возврате управления на клиент происходит передача этого огромного массива данных. Платформа упаковывает его во внутренний формат (схожий с XML), который на стороне клиента должен быть десериализован и помещен в DOM-дерево интерфейса. Это однопоточная операция, которая не только потребляет память, но и на 100% загружает одно ядро процессора, вызывая эффект «зависания» программы.
Проанализируем результаты практических замеров, которые показывают разницу в потреблении ресурсов при работе с 1 миллионом строк (2 колонки типа Строка(10)):
ЗначениеВРеквизитФормы): потребление памяти взлетает до 800–1200 МБ.Как видим, основная «утечка» (которая на самом деле является особенностью архитектуры) происходит именно в момент связывания данных с контекстом формы.
Рассмотрим первый и самый эффективный способ оптимизации. Если нам нужно заполнить таблицу, не обязательно конвертировать всю обработку целиком через РеквизитФормыВЗначение. Попробуем передать только конкретную таблицу.
Вместо того чтобы тянуть весь объект, мы можем использовать передачу конкретного реквизита в процедуру модуля объекта или менеджера. Однако, если мы работаем в модуле формы, разберем следующий прием:
&НаСервере
Процедура ОптимизированноеЗаполнениеНаСервере()
// Не используем РеквизитФормыВЗначение для всего объекта!
// Создаем временную ТЗ, заполняем ее
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Наименование");
ТЗ.Колонки.Добавить("Цена");
Для Счетчик = 1 По 500000 Цикл
НоваяСтрока = ТЗ.Добавить();
НоваяСтрока.Наименование = "Товар " + Счетчик;
НоваяСтрока.Цена = Счетчик;
КонецЦикла;
// Загружаем только данные в реквизит формы, а не весь объект целиком
Объект.ТабличнаяЧасть.Загрузить(ТЗ);
КонецПроцедуры
Важный момент: использование метода Загрузить() для реквизита формы работает быстрее и экономнее, чем полная перекачка объекта через ЗначениеВРеквизитФормы(Объект, "Объект"), так как платформа оптимизирует обновление только коллекции данных, а не всей структуры объекта метаданных.
Когда речь идет о миллионах строк (например, загрузка огромного прайс-листа для анализа), вывод их всех в таблицу формы — это плохая практика. Пользователь физически не сможет просмотреть миллион строк в таблице. Проанализируем архитектурное решение «Сервер — Временное хранилище — Клиент».
ТаблицуЗначений.ВременноеХранилище и сохраняем адрес в реквизите формы.Рассмотрим пример кода:
&НаСервере
Процедура ЗагрузитьДанныеВХранилище()
ТЗ = ЗагрузитьОгромныйФайлНаСервере(); // Возвращает ТЗ с 1 млн строк
АдресХранилища = ПоместитьВоВременноеХранилище(ТЗ, УникальныйИдентификатор);
// На форму выводим только "превью"
Объект.ТаблицаПревью.Загрузить(ТЗ.Скопировать(Новый Структура, "Колонка1, Колонка2"));
// Ограничиваем количество строк для вывода
Пока Объект.ТаблицаПревью.Количество() > 1000 Цикл
Объект.ТаблицаПревью.Удалить(1000);
КонецЦикла;
КонецПроцедуры
Этот подход позволяет избежать «раздувания» памяти клиентского сеанса и зависания интерфейса, сохраняя при этом все данные под рукой на сервере для дальнейшей записи в базу данных.
Выясним еще одну неочевидную причину тормозов: количество колонок в таблице формы. Проанализируем ситуацию: у нас есть таблица с 50 колонками, но пользователю на экране нужны только 5. Даже если колонки скрыты (Видимость = Ложь), они все равно участвуют в сериализации данных формы и потребляют память.
Практический совет: если вам нужно хранить много служебных данных в строках, не добавляйте их как реквизиты таблицы формы. Посмотрите на возможность хранить служебную информацию в отдельной ТаблицеЗначений на сервере (во временном хранилище), связывая её с визуальной таблицей по уникальному ключу (например, номеру строки или идентификатору).
Проанализировав поведение платформы 1С при работе с большими объемами данных, мы можем сформулировать основные правила гигиены кода:
ЗначениеВРеквизитФормы(Объект, "Объект") для объектов с тяжелыми табличными частями. Это главный «убийца» памяти.Загрузить() для конкретной коллекции данных формы.ТаблицаЗначений в памяти сервера — это эффективно, а та же таблица в составе реквизитов формы — это избыточно в 10 раз.Соблюдение этих правил позволит вашим решениям работать стабильно даже на огромных каталогах товаров, а пользователи забудут о сообщениях «Недостаточно памяти» и зависаниях программы.