простейший отчет с запросом:
ВЫБРАТЬ Товары.Ссылка КАК Товар ИЗ Справочник.Товары КАК Товары
Отбор по товару "в списке"

Если в списке 2000 товаров, то при любом клике на форме отчета - жуткие тормоза. Впрочем, тормоза заметны глазу уже на 200 элементах в отборе.
Все это еще до формирования собственно отчета...

Кто нить знает, что там внутри происходит в это время?

Предположу, что неоптимизирована синхронизация контекста формы и при контекстных серверных вызовах список целиком гоняется на сервер.

а каким образом формируется этот список? может сделать как-то иначе?

(1) а есть какой-то способ в этом как то убедиться?
(2) изначально загружается из эксель, при повторном открытии - он уже там

(3) Хороший вопрос. Самому интересно. Самое простое, что приходит в голову - врубить в параметрах запуска имитацию задержек передачи данных серверных вызовов и если характер тормозов совпадет, значит скорее всего оно и есть.

(4) вообще как то странно все, один случайный клик на форме не сформированного еще отчет - и сидим курим )))
...может построитель в это время вычисляет сколько нужно будет вывести строк?

(5) > вычисляет сколько нужно будет вывести строк
Зачем?
ЗЫ. При высокой неопределенности нет смысла гадать. Нужно сначала собрать побольше фактов. Еще по ТЖ, вероятно, можно многое выяснить. Но я не спец по ТЖ.

Если в ТЖ будет чисто и задержки передачи данных на тормоза не влияют, значит тормоза на клиенте. Тогда уже хрен поймешь, где именно накосячено. Нужно будет первым делом проверить поведение на последних релизах и если оно повторяемо - накатать петицию.

а если просто сделать замер производительности и глянуть что он покажет?
(5) вообще странный подход к реализации отбора

(6) я тоже не спец по тх, более того, у нас не всем тж доступен )

Безусловно, большое количество элементов в отборе - это способ замазать архитектурные недоработки. Какого-то признака нехватает.

да нет, при чем здесь архитектура?  запрос в 0 - это чисто для проверки, реально от совсем другой
менеджер формирует файл с нужными ему позициями, скармливает его отчету - получает какой то нужный ему результат

(11) Ну, то что менеджер "формирует файл с нужными ему позициями" в эксель - это тоже недоработка. Значит какой-то бизнес-процесс протекает в экселе, а не в 1С.
Ну, можешь переписать отчет, как вариант. Например, чтобы табличка с данными отбора загружалась во временное хранилище а при компоновке отбор применялся через соединение с ТЗ

Или нет. Зачем через соединение. Можно же просто при компоновке впендюривать этот отбор.

так вопрос то в том, что отчет еще не формировался, а тормоза уже есть (
сейчас сделал замер от "приОткрытии" - пишет результат до 2 сек, а реально - ну сильно дольше

применяй отбор не на форме, а при компоновке результата в модуле

Предлагаю сделать отбор по полю "код" и посмотреть будет ли тормозить так же

(16) Переполучение представлений? Вариант.

(0) а зачем вам этот отбор на форму выводить? Что мешает при компоновке заполнять? А лучше использовать набор данных объект и таблицей через соединение работать с этими 2000+ элементами.