Очень долго открывается документ, в замере производительности самое большое время вверху 2.3 секунды, остальное меньше напорядок, а форма открывается с минуту..сначало думал что замер не идет на клиенте, но отладка на клиенте есть (хоть в отладке в поле пользователь пусто), толине показывает нужное место то ли я чего то не знаю..подскажите плез

что то между присозданиинасервере и при открытии, неужели просто форма так долго с сервера на клиент тянется? другое ничегоне может быть?

форма особо не большая, есть табл документ и четыре тч

(1) Между "при создании на сервере" и "при открытии" происходит инициализация пользовательских настроек, передача всей информации на клиент. Возможно есть ДС с каким-нибудь отбором или еще что-то тяжелое

(3) дс?

(4) динамический список

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

проверь, может быть есть многострочные текстовые поля с БОЛЬШИМ количеством строк (у нас такое было из-за бага конвертации между разными релизами БСП - при каждой передаче задваивало переносы строк и в тех нескольких документах, где был перенос строк в комментарии после пары десятков передач туда-обратно стало оооочень долгим открытие форм)

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

(8) хотя там просто табличный документ в котором всего 500 строк..это много или нет?

(9) ну, на 2 секунды вполне. Так что можешь не париться.

(6) емнп, то дс независимо от видимости все равно "отрабатывает"

1) ДС - отловить можно в ТЖ
2)Сами таблицы на форме имеют 1000 и более элементов - в ход свтупает медлительная клиент серверная оптимизацияю

(9) Особенно если он эксклюзивно покрашен

(9) всего то 500 строк да и еще с ХЗ, в котором непонятно -  что хранится и какого объема...

(14) ну вот я очистил его и моментально открывается, но только и сам табл док не появляется естсно

(14) фишка что там не просто док а дерево в табл доке

(13) это условное оформление имеется ввиду?

Динамическое дерево этот попа...

(18) этов таблинчом доке , который в хранилище значений

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

(20) ну я не особо понимаю чем он тяжелый, 500 строк риали много?,это во первых а во вторых это БИТ ФОРМА ВВОДА бюджета (накосячено за нас)

(21) Это же табличный документ, для него число далеко не единственный параметр определяющий тяжесть. Может там колонок миллион или картинки какие-то нибудь.
Ты попробуй его в файл сохрани, посмотри на его размер.
Еще можно со степенью сжатия хранилища значений поиграться.

(22) проверил с меньшим количеством строк значительно быстрее, не могу понять что там такого на строках навязано.

(21) если это форма ввод абюджета - то проблема в ваших финансистах, а не в документе.
Документа рассчитан на то что в него вносят данные люди и анализируют его тоже люди. А у вас наверно 500 строк и 200 колонок. Столько аналитик никто на самом деле не будет смотреть.
Надо или количество аналитик уменьшать, или на несколько документов дробить.

(24) 456 строк и 18 колонок,открывается непозволительно долго. может что то на строках нагружено ...разве такие доки большие для бюджетирования?

(22) сжатие не помогает(

(25) ну табличный документ - это очень тормозная вещь. Зря ты с ним связался. Возьми таблицу значений. Ну или регистр создай.

Ну в общем, кодить надо, оптимизировать эту лабуду.
Кто-то решил себе упростить жизнь и не париться с сохранением/восстановлением данных этого ТаблДока в нормальный формат, предназначенный для хранения данных.
Но, похоже, что придется этим заняться, если тема долго открытия так важна.

(27) да не я это. а БИТ

(28) а какие способы сохранения и восстановления в нормальный формат?

как раз сейчас оптимизирую бит финанс. Какие-то упоротые ублюдки писали его. Переписал запрос, список документов  выводился 70 сек, стал 10

(30) Встроенный язык 1С:Предприятие

(31) список( а у меня сама форма

(32) типа сохранитьв  тз а потом из тз в табличный снова?

(34) Примерно так, да.
Но чтобы точно сказать надо смотреть что в этом таблдоке хранится и в какой структуре.
Может в ТЗ можно, а может лучше не в ТЗ...

С сервера на клиент должны ехать как можно более компактные данные, а не заполненный таблдок.
По этим данным таблдок на клиенте заполняй, если он и правда нужен для ввода/просмотра.
Потом при сохранении документа обратный процесс.

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

Вот как-то так.
Я все навскидку пишу, не особо вникая, так что где-то могу и ошибаться.

С учетом вышеизложенного может статься, что подождать минуту-другую для открытия, неприятно, но не так уж и печально.
Тем более если это ввод бюджета, а не фронт-офис.