На форме есть 2 динамических списка, динамический список А и динамический список Б, оба одинаковые по своей структуре (различаются лишь по главной таблице), один для документов с покупателем - второй для документов с поставщиком. В них используются группировки дин. списка по документу (ссылке) и из-за этого они очень медленно работают.

Конкретнее - медленно они работают из-за свойства НачальноеОтображениеДерева = РаскрыватьВсеУровни

Но также - там неоптимальный запрос, т.к помимо выборки данных из основной таблицы в нем много соединений (в т.ч с 2 регистрами накоплений).

Начал оптимизацию с того, что свойство "НачальноеОтображениеДерева" определяю программно в событии "ПриОткрытии" (помогло довольно хорошо).

Далее я хотел перенести часть соединений в событие "ПриПолучениеДанныхНаСервере" (получать запросом данные в этом событии и подставлять их в строки), однако вот незадача - это событие ловит строки в зависимости от того, сколько подчиненных строк у группировки, к примеру может быть такое что почти у всех группировок по 1-2 строки, и получается событие отловит их 20-25 раз и все эти разы будет выполняться запрос, а если учесть что списка 2, то и вообще все 40-50.

Подскажите пожалуйста, как можно оптимизировать работу? От группировки отказаться нельзя и объединить 2 списка в 1 тоже

2 отдельных регистра по спискам, заполняемых в фоновом задании, запускаемом в послезаписи всей этой солянки

Сделайте пользователям отчет, а динсписок сделайте нормальным без всяких группировок и соединений.

(2) +++

Купите ребенку компьютер...

(0) Отказаться от ДС (ДинамическийСписок), переписать нафик на ДЗ (ДеревоЗначений)
Там и итоги по группировкам и в подвале легко можно

Кол-во строк ограничить принудительно отборами
Ибо один хрен пользователи не смогут видеть кучу строк разом
Если очень хочется можно даже сделать свою пагинацию, причем с предзапросами в фоне, когда долистали до края фигак и отбор перескакивает дальше с обновление дерева

Пару лет назад на инфостартэвенте как раз такое разбиралось. Там вариант был Дерево на форме и получение данных в момент раскрытия ветки.

начните с группового запроса в ПриПолучениеДанныхНаСервере + проверка индексов. Если не хватит — материализация остатков или дерево значений

Все очень просто. Соберите план - если план плохой - измените запрос. Если план хороший - это уже тяжело. Отборы там курите, ненужные колонки убирайте. Есть методика открытия замера форм, но её ОЧЕНЬ трудно воспроизвести

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

Начните с отказа от динамических списков. Сделайте АРМ.
Специалисты есть (Я), но я не на рынке.
Смотрите мой доклад на Жёлтой конфе 2025 по АРМам