Есть обработка с табличной часть куда загружаем запросом данные.
Проблема возникает при передачи с сервера на клиент, очень много времени занимает, может кто-то сталкивался с таким и как боролся?
Циклов не использую, Выгрузить/Загрузить (запрос очень быстро отдает результат)

(0) А на клиенте то данные эти нужны?

(1)+ Что Вы собираетесь с ними на клиенте делать?

(0)

1) "Очень" это сколько тысяч строк?
2) Не показывайте эту таб.часть на клиенте

Мало контекста. Нужны ли все данные сразу на клиенте или можно показать часть? Если можно - делайте пагинацию своими силами. Примеры запросов можно взять для MSSQL и переделать на 1С. Говорю из собственного опыта.

Второй вариант - передавайте меньше данных. Кодируйте значения, например Перечисление.ВидОперации.Покупка будет символ "1". Колонки типизируйте заранее. На клиенте - раскодирование, будете подставлять нужное значение вместо кода.

(4) О! Кстати интересно, можно ли малой кровью создать ДС к ТЗ которая будет жить на сервере (без сохранения в БД). Или в контексте (0) такая реализация не имеет смысл ил не возможна

(0) Регистр сведений и ДинамическийСписок.
Не забывайте только чистить после работы

(6) ДинСписок к ВТ было бы годно!

(0) код покажи, как ТЧ заполняешь

если вызов неконтекстный - то сделай его контекстным. не крути таблицу на клиенте. всю таблицу на клиент он не всегда тянет, немного подробнее см https://infostart.ru/public/504141/

в некоторых случаях большую таблицу хранить во временном хранилище и на клиент передавать только нужную часть

(9) на сервере процедура, выполняю
порядка 5000 строк,  может быть еще больше.
РезТЗ = Запрос.Выполнить().Выгрузить();
Объект.ТЗДанные.Загрузить(РезТЗ); // около 1-2-х секунд

Все просто, быстро, процедура закончилась на сервере.
Возвращаемся на клиент и тут происходит зависание (дальше на клиенте ни одной строчки кода), может до 20-30 секунд висеть.

(10) спасибо, почитаю

(8) изначально использовал ДС, потом отказались от этого.
Информативно ДС хорошо использовать, но не для постоянной работы со строками.

у меня обработка выступает как пульт оператора, где постоянно фиксируют данные/сохраняют
+ использую функционал отборов свой, где при позиционировании в колонке, предлагает уникальные данные в этой колонке, и так далее по уменьшению в каждой колонке (такого штатным не сделать)

(12) > Возвращаемся на клиент и тут происходит зависание (дальше на клиенте ни одной строчки кода), может до 20-30 секунд висеть.
Ненормально на первый взгляд. Либо что-то все-таки еще происходит, либо таблица реально большая (много длинных строк, например).

(15) подозреваю отрабатывает ПриИзменении на клиенте или нечто вроде

(16) > отрабатывает ПриИзменении на клиенте или нечто вроде.

Тогда это было бы видно в окне отчета замера производительности.

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