да, обещали, но что-то все равно не работает у них ) используем ПоместитьВоВременноеХранилище и оперируем передачей адреса

Вот в сторону с клиента на сервер это видно: если потрогаю все строки ТЧ на клиенте, то серверный вызов (с клиента до перехода на первую строку серверного метода) длится долго, а если не трогаю таблицу формы, то переход на сервер мгновенный.
А вот в обратную сторону всегда, получается, вся ТЧ едет целиком...

В этом случае на форме, получается, нет элемента (таблицы), связанной с ТЧ объекта? Т.е. пользователь на клиенте не работает с содержимым ТЧ?

в этом случае, к сожалению, да. это не ТЧ объекта. Эту ТЧ нужно рисовать

А, т.е. на форме есть реквизит (ТЗ?), с которым связан элемент (таблица) формы?

да

А как отказаться от контекстных, которые работают с ТЧ на сервере? Как содержимое таблицы формы с клиента передавать на сервер неконтекстно (так сказать "своими силами")?
Если через "Для каждого СтрокаКоллекции Из ДанныеФормыКоллекция" то подготовка этого на клиенте и передача на сервер займет еще больше времени, чем сабж (платформенная неявная обратная передача всей ТЧ с сервера на клиент)...

У меня был плохой опыт. Много ТЧ с десятками тысяч строк. Бзик клиента - хочу Эксель. Только запись документа несколько минут происходит.
Логики много, документ огромный.
Все сделано вне контекста. Все летает, кроме открытия и записи. Что можно было разбить на отдельные связанные объекты - разбил.
Да, пришлось самому многое написать. Или типовое, или быстро.
В той же ерп заказы по 200-300 строк - это уже проблема. А десятки тысяч никак не захотят дружить с типовым функционалом.

Переделал в одном месте (не связанном с большой ТЧ) контекстную работу с таблицей формы (деревом значений) на неконтекстную.
Для этого по ходу дела сделал универсальную (рекурсивную) конвертацию ДФД (ДанныеФормыДерево) в массив структур (чтоб потом передавать это в прежнюю серверную логику, но уже неконтекстную, которая на вход ожидает ТЗ).
Конкретно эта операция стала быстрее в несколько раз (по сравнению с прежней 10-15-секундной задержкой на объектах с большой ТЧ).
Похоже пока пойду по этому пути: переделывать контекстные серверные вызовы в неконтекстные (по крайней мере для операций, выполняющихся наиболее часто).

Всего в "несколько раз" ?????
В меня 30+ секундные, задержки  всегда превращались в <1с. Даже на весьма значительных объемах данных выгода была всегда в сотни раз. Главное терминал помощнее и поближе к серверу ))

Выкидывай эту большую ТЧ, переделывай на ДС.
Все равно если не ты, так кто-нибудь после тебя захочет контекстные вызовы использовать в этой форме. А так ты лишаешь всех такой возможности. Путь в никуда.

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

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

У него там вроде одна большая ТЧ. Для нее можно и прокладку в виде ТЗ сделать - зачитываем ДС при открытии / при чтении на сервере в ТЗ, далее работаем на форме только с этой ТЗ (таблицей, с ней связанной), при сохранении объекта уже пишем ТЗ в ДС.
Выгода здесь будет по идее от того, что ТЗ обратно на клиента не будет ехать при каждом контекстном серверном вызове (но это неточно).

- Во что дерево заворачиваете для передачи на сервер? И зачем его передавать, если все расчеты можно выполнить на клиенте?
- НайтиСтроки? Не использовать. Простой обход будет на порядки быстрее.
- Отборы на ТЧ тоже выполняют серверный вызов. ТЧ можно кэшировать известным способом.

Если вообще отказаться от контекстных вызовов, то нет никакого смысла в ТЗ.
PS: в "оффициальном" модуле "Молокозавод для ЕРП" все документы на ТЗ (ради динамических колонок). Это АД (в т.ч. из-за непродуманной реализации). Очень неудобно. Много лишних телодвижений, когда нужно сделать ввод на основании или что-то тривиальное.

Заворачиваю в массив структур. Дальше уже логика работает с ТЗ, задействуя в т.ч. ее платформенные методы (копирование с отбором, сворачивание, поиск).
Писать все свое на клиенте как-то не хочется :)
А как ТЧ лучше кешировать?

Так я про то, что нефиг отказываться от контекстных. Вон чел выше пишет, что неявный возврат ТЗ с сервера на клиент в 8.3.18 вроде как побыстрее проходит. И проблему это доставляет только с большими ТЗ.
Не будет больших ТЗ - не будет проблем и с контекстными.

"А как ТЧ лучше кешировать?"
Имелся ввиду "Полный пустой цикл по строкам" на клиенте (ПриОткрытии), чтобы платформа не дочитывала "порциями ПЕРВЫЕ 35" во время стролингов или отборов по ТЧ.
Для контекстных вызовов это вряд ли поможет.