Здравствуйте.
Платформа 8.3.20, УФ.
Есть таблица на форме, колонок 10-15, строк 10-15 тысяч. Сам отчет формируется довольно долго. Но проблема даже не в этом. Когда становишься на строку и жмакаешь "End" все замирает на минут 5-7, иногда 10, и только тогда просходит отрисовка и курсор отображает в конце таблицы.
Подскажите с как можно, и можно-ли вообще что-то сделать для ускорения процесса работы с таблицей?

Ссылочные типы выводишь ведь?

Не только.

если включить показатели производительности, то видно, что оно всю таблицу маленькими кусочками на клиент передает. Решением может быть формирование отчета неконтекстным серверным вызовом с возвратом табдока.

(0) ежели не секрет, а что вы делаете с 200 000 значений? На для ускорения можно "таблицу" выводить динамческим списком...

(3) а у него табдок или таблица?

если таблица, то решение примерно то же самое

(3) Таблица формы.

вот описание эффекта https://infostart.ru/1c/tools/504141/

(8) не, все делается в контексте.

(9) "Естественно, никого обмануть не получится, и, например, при печати или поиске документ так или иначе будет получен на клиенте."

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

Да, блин, все формируется на сервере и заполняется таблица соответственно там. Значит все таблица уже на клиенте. И тут начинаются тормоза.

Отрисовалась таблица. Ставлю курсор на вторую строку таблицы - и все 1с уходит в коматоз.

Процесс на клиенте "Не отвечает". На сервере 1c особо никаких экстремумов не наблюдается. Сетка между СУБД и 1с сервером 10Gb.

Между клиентом и сервером 1с тоже 10Gb.

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

(16) Да, это не моя таблица... Там отчет, звездец...

(16) Ну думаю что дело именно в передаче всей таблицы... Хрен с ней, сформировалась она, а дальше с ней практически невозможно работать как в (13)

(18) *Ну думаю = Не думаю.

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

(18) все правильно тебе говорят, попробуй на клиенте запусти после заполнения

Для каждого Строка из МояТаблица Цикл
КонецЦикла;

в этот момент вся таблица будет получена на клиент, при этом потормозит - зато потом будет летать

(18) ну включи показатели производительности и смотри на счетчики количества вызовов и объема переданных данных

(21) вроде бы этот способ по времени просто перенесет тормоза непосредственно в точку формирования отчета. Неконтекстный же вызов будет сильно быстрее, так как это будет одно взаимодействие с сервером. Надо счетчики смотреть.

Сделать неконтекстный вызов не получится. Надо будет переписывать все, а это нереально...

(24) думаю, что далеко не всё. ну, конечно, если твой выбор - страдать, тогда да. ну можешь еще костыль из (21) вставить, чисто чтобы убедиться, что причина в этом, но это приведет к тому, что просто дольше всё будет формироваться.

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

Выведи отчет не на форму,а в табличный документ. Добавь расшифровку

(26) да большой табдок тоже медленно работает

(0) Можно. Дать пользователю сразу те 2-3 цифры, ради которых формируется эта 15-тысячная простыня.