Имя: Пароль:
1C
1С v8
УФ. Отчет СКД и относительно большое количество элементов в отборе
,
0 palpetrovich
 
27.01.22
10:31
простейший отчет с запросом:
ВЫБРАТЬ Товары.Ссылка КАК Товар ИЗ Справочник.Товары КАК Товары
Отбор по товару "в списке"

Если в списке 2000 товаров, то при любом клике на форме отчета - жуткие тормоза. Впрочем, тормоза заметны глазу уже на 200 элементах в отборе.
Все это еще до формирования собственно отчета...

Кто нить знает, что там внутри происходит в это время?
1 fisher
 
27.01.22
10:34
Предположу, что неоптимизирована синхронизация контекста формы и при контекстных серверных вызовах список целиком гоняется на сервер.
2 DrShad
 
27.01.22
10:35
а каким образом формируется этот список? может сделать как-то иначе?
3 palpetrovich
 
27.01.22
10:36
(1) а есть какой-то способ в этом как то убедиться?
(2) изначально загружается из эксель, при повторном открытии - он уже там
4 fisher
 
27.01.22
10:40
(3) Хороший вопрос. Самому интересно. Самое простое, что приходит в голову - врубить в параметрах запуска имитацию задержек передачи данных серверных вызовов и если характер тормозов совпадет, значит скорее всего оно и есть.
5 palpetrovich
 
27.01.22
10:43
(4) вообще как то странно все, один случайный клик на форме не сформированного еще отчет - и сидим курим )))
...может построитель в это время вычисляет сколько нужно будет вывести строк?
6 fisher
 
27.01.22
10:46
(5) > вычисляет сколько нужно будет вывести строк
Зачем?
ЗЫ. При высокой неопределенности нет смысла гадать. Нужно сначала собрать побольше фактов. Еще по ТЖ, вероятно, можно многое выяснить. Но я не спец по ТЖ.
7 fisher
 
27.01.22
10:49
Если в ТЖ будет чисто и задержки передачи данных на тормоза не влияют, значит тормоза на клиенте. Тогда уже хрен поймешь, где именно накосячено. Нужно будет первым делом проверить поведение на последних релизах и если оно повторяемо - накатать петицию.
8 DrShad
 
27.01.22
10:49
а если просто сделать замер производительности и глянуть что он покажет?
(5) вообще странный подход к реализации отбора
9 palpetrovich
 
27.01.22
10:49
(6) я тоже не спец по тх, более того, у нас не всем тж доступен )
10 fisher
 
27.01.22
10:50
Безусловно, большое количество элементов в отборе - это способ замазать архитектурные недоработки. Какого-то признака нехватает.
11 palpetrovich
 
27.01.22
10:53
да нет, при чем здесь архитектура?  запрос в 0 - это чисто для проверки, реально от совсем другой
менеджер формирует файл с нужными ему позициями, скармливает его отчету - получает какой то нужный ему результат
12 fisher
 
27.01.22
10:57
(11) Ну, то что менеджер "формирует файл с нужными ему позициями" в эксель - это тоже недоработка. Значит какой-то бизнес-процесс протекает в экселе, а не в 1С.
Ну, можешь переписать отчет, как вариант. Например, чтобы табличка с данными отбора загружалась во временное хранилище а при компоновке отбор применялся через соединение с ТЗ
13 fisher
 
27.01.22
11:00
Или нет. Зачем через соединение. Можно же просто при компоновке впендюривать этот отбор.
14 palpetrovich
 
27.01.22
11:14
так вопрос то в том, что отчет еще не формировался, а тормоза уже есть (
сейчас сделал замер от "приОткрытии" - пишет результат до 2 сек, а реально - ну сильно дольше
15 DrShad
 
27.01.22
11:16
применяй отбор не на форме, а при компоновке результата в модуле
16 toypaul
 
гуру
27.01.22
12:32
Предлагаю сделать отбор по полю "код" и посмотреть будет ли тормозить так же
17 fisher
 
27.01.22
12:35
(16) Переполучение представлений? Вариант.
18 Kassern
 
27.01.22
12:39
(0) а зачем вам этот отбор на форму выводить? Что мешает при компоновке заполнять? А лучше использовать набор данных объект и таблицей через соединение работать с этими 2000+ элементами.
Закон Брукера: Даже маленькая практика стоит большой теории.