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

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

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

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

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

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

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

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

(2) +++

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

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

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