Разработка нетипового функционала под отраслевое решение, управляемые формы, база mssql
Разрабатывается документ, в котором 20 табличных частей. При  этом, максимальное количество строк для каждой табличной до 100.
На форме документа табличные части располагаются на разных страницах.
Планируемый объем документов ~50 тыс. в месяц. Есть ли опыт, влияет ли указанное количество ТЧ на отрисовку интерфейса при открытии формы?
Я понимаю, что возможно сделать тестирование и набросать в систему данные самостоятельно, но надеюсь,  что кто-то сталкивался с подобным и поделится опытом.

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

Кстати, как называется документ?

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

(0) Количество элементов на форме на скорость ее отрисовки не влияет. Но тыж их не просто показать хочешь. Ты их данными заполнять будешь. А вот тут уже куда интереснее будет.

Да и вообще больше пяти табличных частей в доке это уже перебор, что-то неправильно спроектировано в архитектуре.

(5) чойта вдруг?

документ Корректировка регистров в ERP, например :)

настраиваешь состав, да хоть 100

(5) очередной отчёт внутри документа.
ничего нового.

(6) Там нет табличных частей

(8) там есть одна табличная часть (в пофигураторе заданная)

а по составу регистров динамически рисуются страницы с таблицами движений с колонками (ссуть ТЧ в контексте обсуждения) для выбранных регистров сведений/накоплений

(6) Не путай рабочий док и редкий инструмент. В док человек сморит. Он там должен что-то увидеть, что-то набить.
Так он уже после десятой ТЧ забудет что за док он рихтует.

(10) в док человек биоробот может кнопку загрузить нажать или заполнить и магия на овер много ТЧ произойдет. каким-нибудь отчетом потом результат проверят

если нужен док на 20 ТЧ. пусть будет. 1С не треснет

(0) Основные тормоза будут когда начнешь скакать с клиента на сервер. Отрисовка интерфейса она быстрая...

(12) этот момент сведён к минимуму. Либо клиентские вызовы, либо серверные без контекста
(6) данные разнесены по страницам, являются оцифрованным отображением работы человека.

Вопрос по табличным частям задал по следующей причине. Несколько лет назад делал биллинг, но там было 3 табличных части и в каждой могло быть до 100 тыс. строк. Столкнулся с тем, что при открытии документа, если количество записей в табличных частей больше 10 тыс., наблюдаются тормоза. При этом, скорость замера в отладчике не показывала криминала, более того, там не было указания на 10-ти секундный лаг при открытии формы.
Дальнейший анализ показал, что при открытии дока, 1с считывает все табличные части целиком, даже в том случае, если на первой странице - поля без табличных частей, а на другой форме, в грид входит только 40 записей. Получается, считывается весь пул информации при открытии формы, а отображается 40 строк.

(13) Ну да - весь. Читается же объект целиком

(13) может, есть смысл хранить всё в регистрах? табличные части нужны для забивания данных людьми. сомневаюсь, что они тысячи строк дубасят. на этапе проектировки сразу такое надо продумывать. что должно быть реквизитом, что - сведением

(13) глянь механизъм Корректировка регистров в типовой.

по аналогии можно свой документ "запилить", данные документа (ссуть регистратор) можно в регистрах хранить.

(15) после результатов анализа, сделал на регистрах. Для этого объекта  чтение из БД идёт порционно и зависит от количества строк в гриде. Форма стала открываться очень шустро.

(11) Да пусть будет. Тока это больше на отчет похоже, чем на док.

(18) А может это обработка типа АРМ?

(19) Может быть. У меня так технолог хотел, тащить данные с оборудования в док. Уговорил на регистры и красивый многостраничный отчет.

Я за обработку.