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

&НаКлиенте
Процедура Рассчитать()

    Н = 1;
    Для Каждого СтрокаДФ Из Объект.Расходы Цикл
        Н = Н + 1;
    КонецЦикла;

КонецПроцедуры

И эта процедура очень сильно тормозит. Замерил отладчиком - на 139 вызовов строки "Для Каждого СтрокаДФ Из Объект.Расходы Цикл" ушло 10 секунд времени. Походу, при каждом повторе цикла происходит какой-то неявный серверный вызов? Тогда как оптимизировать обход всей ТЧ? Если процедуру вызывать "&НаСервере", то накладные расходы при передаче контекста на сервер из-за большого объема ТЧ тоже велики - около 3 секунд, поэтому я и не хочу передавать вызов на сервер, все нужные данные, по идее(?), должны находиться на клиенте - ТЧ Расходы. Как сделать максимально быстрый обход всей ТЧ на клиенте?

на клиенте подтягиваются только видимые строки.
когда ты тих обходишь, то подтягиваются все

не показывай тч вообще, или на отдельной закладке

(0) При повторном нажатии Рассчитать всё считается быстро?

(2) Не помогает. Я вообще скрыл с формы ТЧ Расходы - скорость не изменилась.

Н = 1;
    Для Каждого СтрокаДФ Из Объект.Расходы Цикл
        Н = Н + 1;
    КонецЦикла;

- какой в этом смысл? Пиши Н = Объект.Расходы.Количество()

(3) Повторного нажатия я не могу дождаться, терпения не хватает))

(5) Думаю, расчет сложнее )

(5) тебе знакомо понятие "минимальный пример"?

вот будет прикол, если расчет не сложнее =))

(5) Это я специально упростил пример. Не должно столь простое выражение так медленно работать. Мне нужен расчет посложнее, вроде

Для Каждого СтрокаДФ Из Объект.Расходы Цикл
        Если СтрокаДФ.Поле1 = Значение1 Тогда
                Результат = Результат + СтрокаДФ.Сумма2;
        КонецЕсли;
КонецЦикла;

(8) +1

(10) дело в (1)

делай на сервере

(4) скрыл, но делаешь на клиенте? так не пойдет

(9) Не гони чувак, у меня полоска подлиннее твоей!

(10) Тоже лажа. Отбирай нужный строки через НайтиСтроки и бери итог по колонке "Сумма2".  Нет смысла перебирать строки.

(14) (10) Можно попробовать выбирать данные запросом с выгрузкой в ВТ или через найтиСтроки

(12) Не хочу делать на сервере, потому что, повторюсь, каждый вызов сервера - это плюс 3 секунды, а это тестовый пример. В рабочей базе по 100 000 строк будет, там переход на сервер будет дороже 3 секунд.

(15) НайтиСтроки() - неявный серверный вызов! В моем случае, это плюс несколько секунд!!!

(17) проверял? т.е. ходить каждые ~15 строк на сервер - норм, а один раз - не норм?

Показывай уже полный алгоритм.

(18) ну не сделаешь ты без серверного вызова. либо грузить в
&НаКлиенте
ПЕРЕМ МоиМегаДанные
в ПриОткрытии и/или чтении и как-то синхронизировать.

(17) без отображения тч сколько серверный вызов занимает?

вот тут есть кое что: http://catalog.mista.ru/public/504141/
проще всего включить показатели производительности и смотреть за объемом передаваемых данных и количеством вызовов

(20) Ну вот полнее:

        //тут происходит невяный серверный вызов для НайтиСтроки()! поэтому переделал для клиента
        //СтрокиРасход = Объект.Расход.НайтиСтроки(Новый Структура("ИдентификаторСтроки", ИдентификаторСтроки));
        
        //Для Каждого СтрокаРасход Из СтрокиРасход Цикл
        //    СуммаРасход = СуммаРасход + СтрокаРасход.Сумма;
        //КонецЦикла;
        
        //тут тоже получаеся неявный вызов(?)
        Для Каждого СтрокаРасход Из Объект.Расход Цикл
            Если СтрокаРасход.ИдентификаторСтроки <> ИдентификаторСтроки Тогда
                Продолжить;
            КонецЕсли;
            СуммаРасход = СуммаРасход + СтрокаРасход.Сумма;
        КонецЦикла;

нужно еще учитывать, то найтисроки по тч не использует индексов, тк в тч их нет

Оптимальный вариант  - однократно итоги считать на сервере приОткрытии/Заполнении. И пересчитывать при обработке ПриИзменении/Добавлении/Удалении.

Геморно, но быстро в итоге.

(25) Если все на сервере выполнять, то для 10000 строк НайтиСтроки быстро работает и без индексов, но я хочу попытаться все на клиенте сделать, по логике вещей, для данной задачи мне сервер не нужен, данные все есть в ТЧ на форме.

(22) ровно столько же, как и с отображением ТЧ на форме

&НаСервере
Функция РассчитатьНаСервере()
    ТаблицаРасходов = Объект.Расход.Выгрузить(Новый Структура("ИдентификаторСтроки", ИдентификаторСтроки));
    Возврат ТаблицаРасходов.Итог("СуммаРасход");
КонецФункции

Неужели будет работать медленнее с любым количеством строк, чем что-то на клиенте изображать?

(27) нет. у тебя только выделенные + закэшированные строки

(27) Делай на сервере.

Зачем на УФ 10 тыс. строк? Кто их смотрит?
Если нужно посмотреть, выводите печатную форму.

(21) Да, спасибо за совет. В ходе экспериментов, оптимальным с точки зрения производительности получился такой алгоритм:
- делаем глобальную переменную модуля &НаКлиенте Перем КешРасходы;
- при открытии формы &НаКлиенте запросом читаем ТЧ и выгружаем как ТЗ в КешРасходы (0.2 секунды для 10000 строк!)
- при необходимости расчета, ищем данные через процедуру &НаКлиенте в таблице КешРасходы (также доли секунды)
- при модификации ТЧ Расходы, самостоятельно апдейтим КешРасходы
- при сохранении как-нибудь синхронизируем Объект.Расходы и КешРасходы
- мне кажется, в данном случае лучше самостоятельно лепить форму работы с документом через внешнюю обработку, чтобы самому контролировать чтение и запись данных и избавиться от передачи туда-сюда ненужного контекста.

Короче, приходится полностью переделывать работу с ТЧ, но это реально! Напоминает костыли при разработке на 7.7. Резюме: разработчики механизма УФ - МУДАКИ! Не удивлюсь, если они при передаче контекста между сервером и формой парсят все данные в XML и обратно, благодаря чему ненужный трафик между формой и сервером и нагрузка на процессор вырастают в десятки раз. Но зато это, ИДЕОЛОГИЧЕСКИ правильно! Все ПО СТАНДАРТУ! Когда производительность компов снова вырастит в 200 раз, мы будем с улыбкой вспоминать об эти ЧУДОВИЩНЫХ тормозах.

> парсят все данные в XML и обратно
все так и есть

на самом деле избавится от лишней передачи данных клиент-сервер можно и в большинстве случаев достаточно просто

*ться

(35) И как же? Посоветуй, плз!

(35) &НаСервереБезКонтекста?

(37)(38) не тянуть на клиент, например.

(33) ТЗ на клиенте нет. Массив хранить?

(40) Прикол в том, что ТЗ на клиенте ЕСТЬ)))
Ты легко можешь на клиенте выполнить запрос и выгрузить его результат в ТЗ! И хранить ТЗ в глобальной переменной модуля формы!

ТЗ = Запрос.Выполнить().Выгрузить();

Вот такие костыли, ребята, спасибо 1С хоть за это!

(39) Каким образом? Я не очень еще разобрался в этом механизме.

(41) ну это только в толстом клиенте. передать клиент-сервер ты не можешь.

(42) не делать контрол с путем к большим данным

(44) Точно! Я скрыл контрол, но он, походу, все равно передается. Попробую его прибить.

(45) ну там еще в разных платформах по разному оптимизировали + хз как оно работает в толстом клиенте

(43) Я на толстом работаю, но с УФ.

(47) не самый оптимальный вариант

(47) Ну такое себе на самом деле. Я раньше тоже на толстом работал, так как только так консоль запросов нормально работала. Но после пары ошибок сериализации, включил тонкий клиент. А там и консоль запросов нормальную подвезли)
На самом деле было бы инетересно посмотреть, что станет с производительностью, если заменить ТЗ на массив.

например все интерфейсные действия стандартного отчета ОСВ из бухни ооооооочень сильно тупят (например выбор счета с другим составом субконто) в таком варианте

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

>в нем даже простой перебор работает настолько медленно,что возникает желание вообще с данными не работать

ну это только в 1с так. если по человечески писать - вполне себе работает. в этом плане от vuejs тащусь.

(48) (49) Не мой выбор) Приходится изворачиваться на том, на чем корпоративная система работает.

(51) Это да. На сервере данные не храни - а то юзеры сервак перегрузят, но на клиенте тоже не храни - слабый веб-браузер может не вывезти. Идеология клиент-сервер от 1С - нигде данные не храни, а гоняй туда-сюда, причем зачастую вместе с избыточными данными, да еще в виде неоптимального с точки зрения ресурсов XML!

(54) вроде данные передаются в json, а не xml

(55) Может, и в json, но факт в том, что механизм обмена данными клиент-сервер реализован крайне неоптимально

(56) А как можно оптимальнее реализовать?

(57) Наверное, как-то можно. Тут вопрос философский: вроде, как 1С развивается в сторону работы с большими объемами данных и подключенных пользователей, но интерфейс простых объектов с каждым новым глобальным обновлением работает все медленнее и медленнее. Вспомните, как быстро летала семерка на первых пнях, конечно, если объем данных был не очень большой. Но в вышедшей затем восьмерке на таких же данных формы работали заметно медленнее. Потом когда компы только начали более-менее нормально тянуть восьмерку, 1С выпустили тормознутые УФ, потом этого им показалось мало - вот вам Такси! Управляемые формы даже всего с несколькими десятками статичных контролов и для пустых объектов заметно притормаживают. Для сравнения вспомните старые добрые игрухи, на еще старых компах без 3D-акселераторов - на экране сотни движущихся динамичных объектов с меняющимися текстурами, и все плавно движется и быстро масштабируется! Потому что в одном случае была оптимизация, а в другом - не особо.

(58) Ну да, на оптимизацию забивают. Вкладка в Хроме с пустым письмом-черновиком несколько сотен мегабайт ОЗУ занимает

(58) Об этом уже на habre не одну тему сделали. На гугл почту сейчас ругаются, до этого тоже похожая тема была. Скайп от МС тоже тормозит нещадно.

а овер 99 999 строк давно стало в ТЧ объекта влезать?

"Скайп от МС тоже тормозит нещадно" // Скайп Лайт под МУ вообще норм работает

(44) Кстати, я выяснил, что это не помогает! Я создал абсолютно пустую форму, без единого контрола, но если там основной реквизит - документ объект, то при открытии этой пустой формы на форму неявно передаются все данные из реквизита Объект, в том числе данные табличной части, у которой нет даже отображения на форме! То есть, пустая форма документа с табличной частью из 10 строк открывается почти мгновенно, а если в табличной части 50000 строк, то эта пустая форма без отображения чего-либо и без единой строчки кода открывается 15 секунд! Получается, данные табличной части при открытии на форму передаются, но когда я в контексте этой формы пытаюсь сделать простой перебор этой табличной части (Для Каждого СтрокаДФ Из Объект.Расходы Цикл), при каждой итерации все равно происходит обращение к серверу! Логике такое поведение не подвластно!

(3) При повторном нажатии, если его дожаться, действительно, все быстро работает)

(63) а флаг "использовать всегда" у табличной части в реквизитах объекта снимал?

(63) Писец.
Откройте для себя флаг "Использовать всегда"

(65) Попробовал снять флаг. Стало быстрее работать, да, но все равно форма с маленькой ТЧ открывается мгновенно, а с ТЧ 50000 строк - 3 секунды (спасибо, хоть не 15, как раньше)

(66) Флаг снял, но все равно это не отменяет ситуацию, при которой при установленном флаге на форму передаются непонятно какие данные, так, что при переборе ТЧ идет постоянное (и медленное!) обращение к серверу.

(67) Ну создание и чтение объекта (не объекта формы) на сервере это не отменяет, может там ещё обработчики какие есть.

+(69) попробуй просто в коде получитьОбъект() выполнить и сделать замер, для пустого и для 50к

(69) Я специально создал голую форму без обработчиков и каких-либо реквизитов) В коде замер сложно делать, поскольку прорисовка форма идет после отработки основных событий формы, я секундомером замерял

(71) Так я тебе про это говорю, возможно 3 секунды - это время отработки на с сервере условного "ПолучитьОбъект()", а клиент-серверное взаимодействие в таких условиях происходит мгновенно.

(68) понятно какие. про это в (23) написано

"создал голую форму без обработчиков и каких-либо реквизитов" // Так. А что с чем сравнивал?

(67) а по это - в (30)

(75) Так у него форма уже вроде как голая, вообще без элементов

Создал док на 50кстрок.
На холодном кэше SQL+1С - время открытия - 5.58 сек, отправлено данных 1512 байт, принято 116220 байт.

На горячем кэше SQL+1С - время открытия - 4.44 сек, отправлено данных 1048 байт, принято 115230 байт.

Выборка не совсем достоверна, в дублях строк - дубли ссылочных данных, но все равно, она показывает 4.4 секунды сериализации и 1.1 секунд выборки данных.
Выбирайте ваш сервер 1С правильно, бать вашу Билла Гейтса, сколько вам талдычить :-)

Сжатие - усиленное.
Сейчас обычное включу, 4.4 секунды превратяться в 3.4 секунды, вот увидите.

Очень странно - время открытия - теже 4.4 секунды.
Неужели SDH оптимизировали.

SDC

(74) Сравнивал голую форму документа с ТЧ 10 строк и другим документом с ТЧ 50000 строк

(81) Сравни кол-во байт в показателях производительности

(77) Так ты давай замеры с документом на 10 строк теперь

(83) Тунца

(84) Айфонами не пользуюсь, хз о чем ты.
Какой прок от твоих обозначенных выше 4-5 секунд без сравнения?

(63) А что вас смущает? вообще так и должно быть. Как только код вернулся на клиент, серверный объект (ДокументОбъект) уничтожается.

В этот момент данные должны быть все на клиенте, чтобы потом можно было восстановить ДокументОбъект при записи.
Это в статьях 1С расписано, по другому не сделать. Соответсвенно, нужно это учитывать при проектировании форм, возможно хранить данные по другому.

(86) Так форма-то пустая, на клиенте никакой ТЧ в этом случае нет

(68) А с "данные формы коллекция" у 1Сников сделана некая оптимизация (со списком например, такой оптимизации нет) - на форму передается только порция по 20 строк. Как только список докрутился до конца - с сервера тащится еще 20 строк. На сервере ТЗ хранится во временном хранилище.
Так что рассчитывать какие-то итоги по табчасти на клиенте - это не оптимально. Нужно отправлять код на сервер и там эти итоги считать. А результат (сумму) хранить в добавленном реквизите формы.

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

(88) "рассчитывать какие-то итоги по табчасти на клиенте - это не оптимально" - неоптимально, исходя из кривости реализации УФ! Исходя из нормальной логики, как раз должно быть оптимально, раз и так данные формы передаются на форму (если не снят флажок "Использовать всегда"), то зачем делать ненужный вызов сервера? В моем случае каждый вызов сервера - это несколько секунд, все тормозит нещадно. Поэтому тут лучше самостоятельно получать нужные данные на форму, где их и хранить, и без обращения к серверу рассчитывать из этих данных итоги.

(89) Нет никакой ДФК, т.к. на форме такого реквизита нет

(90) "раз и так данные формы передаются на форму" выяснили же, что передаются частями.

(92) Да вообще не выяснили! Какими частями? Если так, то время открытия формы на 100 строк и на 10000 должно быть одинаковым - туда 20 видимых строк подгрузились, и туда 20 строк, но разница во времени открытия - в разы!!!

(93) перейдите на тонкий клиент. Возможно, в толстом на клиент передается вся табчасть, а не порциями.

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

(93) твое "время открытия формы" это не только передача контекста на клиент и отрисовка, но и чтение объекта (целиком!) на сервере, поэтому разница

(95) "как нет" // Так нет.
"откуда тогда система знает, что записать в табчасть документа?" // Ей это не надо знать, т.к. ТЧ никак изменена быть не может, т.к. нет ни элемента формы, ни реквизита этой формы, олицетворяющих эту ТЧ.
Как это внутри: думаю, система просто видит, что на сервер с клиента не прилетела "дельта" (изменения) по ТЧ и поэтому тупо ничего не делает с этой ТЧ.

(96) Ты и в (72) про это говорил, очевидно же что не в коня корм )

(98) Повторение - мать учения

(100)!!

Вдогонку: как же все-таки убого реализованы управляемые формы, простейшая запись без проведения и каких-либо обработчиков из формы документа с 20000 строк занимает 4 минуты в случае УФ, и 3 секунды, если вместо управляемой поставить обычную форму!

(101) а я все думаю, зачем клиент-сервер вообще впилили эти долбаные индусы

+(102) походу они были не в курсе что бывают доки тч в 50к строк

в теории на клиенте 20 тыщ строк - это совем не много. ну 20-200 мегабайт

(104) а если у тс есть поле с типом хранилище...

(101) а сколько раз оно сходило на сервер, если смотреть на счетцики?

*ч

(101) Отличный индикатор криворуков.

Ещё меня забавляют фразы "приложении xxx любит процессор" "приложении yyy любит память". Мрак.

(109) ну зачем ты так, у него полоска длиннее

(0) Прочитать мануал,осознать что на клиенте нету этой тч, дфк это имитация, на клиент передается по 15 строк, сколько там обращений при обходе на сервер боюсь даже представить. Решение одно - выполнить этот код на сервере.
При переходе с клиента на сервер дфк обратно не передается, передаются только измененные элементы.

(0) "В этой ТЧ 10000 строк"
В чем суть задачи ? нафейхуа так делать ?

(101) а теперь представь что все это должно работать еще и в браузере и на мобильной платформе

(101) простейшая запись-очень интересно) что проведение/что запись для субд это необходимость нахерачить в таблицу кучу данных, в твое случае 20000 строк. Но судя по всему говнокод рулит.

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

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

(116) +1

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

(118) Делайте его в фоне и не смотрите.
Но вообще - порочная практика - большие ТЧ, все кого знаю на РС перешли.

(118) ага, точно, технический документ, который нужно открывать, причем в некой тч перебирать 50к строк, ну, а почему бы и нет

(120) я проф в 8.2, но в душе я семерошник

(0) "в данном примере будет рассмотрен другой вопрос: где наиболее эффективно выполнять пересчет большого количества строк табличной части – на сервере или на клиенте?"
https://its.1c.ru/db/pubv8devui#content:296:hdoc

Вите надо выйти.