Всем доброго времени суток.

На форме размещен Динамический список:
Основная таблица - справочник.
Вид ключа - Авто.
Динамическое Считывание данных - да.

Требуется установить отбор "Ссылка в СписокЗначений".

Для отбора элементов справочника по заданному списку я пробовал как добавлять СписокЗначений в качестве параметра в запрос динамического списка, так и устанавливать отбор через "ЭлементОтбораКомпоновкиДанных".

В обоих случаях все замечательно работает до тех самых пор пока количество элементов в СписокЗначений не перевалит примерно за сотню.
Если СписокЗначений толстеет, то сразу получаю тормоза при работе с указанным Динамическим списком - переходы между строк начинают занимать по 5 и более секунд.

Замер производительности показал, что узким местом является обработчик "ПриАктивизацииСтроки" данного ДинамическогоСписка, в котором вызывается серверная процедура, выполняющая несколько запросов к регистрам сведений по текущему элементу ДинамическогоСписка.

Получается ситуация:

```1c
    &НаКлиенте
    Процедура СписокПППриАктивизацииСтроки(Элемент)
    ЗаполнитьРеквизитыТекущегоПП(Элемент.ТекущаяСтрока); //96% процессорного времени - 5 секунд
    КонецПроцедуры

    &НаСервере
    Процедура ЗаполнитьРеквизитыТекущегоПП(ПотенциальныйПользователь)
    // тут 3 запроса, каждый из которых занимает мене 1% процессорного времени - менее 0.5секунд.
    КонецПроцедуры
```

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

И я не понимаю почему. Куда пропадает 95% процессорного времени? Оно же не может пойти в пустоту?
Если Список значений очистить или закомментить обработчик "ПриАктивизацииСтроки" тормоза полностью проходят.

ЧЯДНТ?

==============================================
Как обычно, стоило спросить, и похоже, я сам нащупал суть проблемы.
Судя по всему замер производительности на сервере штука весьма условная. Данные, которые он отображает не имеют ничего общего с реальностью...
---
Да дело оказалось не в отборах вовсе.

Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.

Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
---
может здесь найдешь ответ
---
Да дело оказалось не в отборах вовсе.

Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.

Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
---
У Вас же серверный вызов при активизации строки, надо подключать обработчик ожидания.
---
Да, оказалось полезным, спасибо.
---
да и использовать в этом обработчике стоит только серверные процедуры "&НаСервереБезКонтекста".

Хоть разработчики платформы и заявляют, что при использовании "&НаСервере" передаются только измененные данные формы, а данные динамических списков не передаются вовсе. По факту это не совсем так.

Ради интереса поместил в СписокЗначений 50000 элементов и передал их в параметр ДинамическогоСписка. Получил тормоза, время вызова сервера выросло с 0.08 секунд до 2.

Переписал механизм заполнения реквизитов формы при активизации строки используя только "&НаСервереБезКонтекста" - время вызова сервера 0.03 секунды =).
---
А зачем мучаться с вызовом сервера каждый раз при активизации строки?
Мне кажется лучше использовать обработку события списка ПриПолученииДанныхНаСервере()

Она выполняется НаСервереБезКонтекста... и лишних телодвижений не надо.
---
ПриПолученииДанныхНаСервере()
Конечная цель - заполнение реквизитов формы при смене строки динамического списка.