Доброго времени суток! Имеем таблицу значений которая лежит на УФ. ТЗ имеет порядка 20 колонок и 700 строк в среднем. На форме она имеет тип соответственно "ДанныеФормыКоллекция". Конструкция вида: ТЗ.НайтиСтроки(Новый Структура("Поле1,Поле2", Значение1, Значение2)); приводит к замиранию на целых полсекунды. Из за чего при работе с формой возникает неприятный лаг. Если ли вариант как-то ускорить процесс? Потому, что как наложить индексы на "ДанныеФормыКоллекция" я не нашел.

Я заново выводил на форму выбранную инфу, которая выбиралась из данных объекта, а не из данных формы

(0) Выгрузить в ТЗ обычную, добавить индексы, искать. Продумать соответствие номеров строк меджду строками на форме и в ТЗ.

Причем выгружать в ТЗ не все колонки таблицы, а только те, которые используются при поиске.

(0) где выполняется данная конструкция? Если на сервере, то возможно сам поход на сервер для такой формы занимает полсекунды и оптимизация поиска ничем не поможет.

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

(4) НайтиСтроки

Доступность:

Тонкий клиент, веб-клиент, мобильный клиент, сервер, толстый клиент, мобильное приложение(клиент), мобильное приложение(сервер).
Вызов метода выполняет обращение к серверу.

(1)(2)Не очень хочется на каждый чих ходить на сервер.
(5)Есть общая таблица с общими данным, пользователь щелкает по строкам получает в другой таблице, развернутую информацию.
(6)Это беда печаль конечно. Таблица лежит на клиенте, но что бы сделать поиск нужно все равно ходить на сервер. Очень плохо. Придется все переделывать, раз уж он все равно генерит обращения к серверу.

(7) не надо ходить на сервер чтобы найти строки. делайте на клиенте

(8)Каким образом? Перебором? Единственный метод который делает поиск по коллекции генерит как выяснилось(слона то я и не заметил), неявное обращение к серверу.

(9) ТЗ.НайтиСтроки где делаете, на сервере или все же на клиенте?

(0) https://its.1c.ru/db/v8std#content:-2145783019:hdoc

Видел на инфостарте свою реализацию индексов на клиенте с помощью соответствия.

(10) перечитай еще раз текст в (6)

(13) я знаю про вызов сервера, но найтистроки на клиенте отрабатывает все равно быстрее

(7) // Есть общая таблица с общими данным, пользователь щелкает по строкам получает в другой таблице, развернутую информацию.

Значит уже не нужно ничего искать. Данные строки уже должны содержать ссылки на элементы коллекции до момента клика

(14) найти строки по значениям из коллекции в 700 строк и 20 столбцов за полсекунды - это довольно быстро :-)

(16) провел опыт.
тз на форме 5 колонок и 10 тыс. строк

тз.НайтиСтроки(Новый Структура("Реквизит1,Реквизит2","1", "2"))

на клиенте 3 милисекунды
на сервере 280 милисекунды

но
первый запуск метода на клиенте отрабатывает 1.5 секунды, далее 3 мс

(17) кеширование? не, не слышал

(18) оно самое

(7) Так если вопрос отображения, может просто отборы переключать?

(10) Поиск происходит на клиенте. Вопрос в (0) как делать поиск быстро и не ходить при этом на сервер за ТЗ с индексами. Но судя по (6) и (11) никак
(17)Спасибо большое, но поиск от этого быстрее не стал.
(15) Как вариант

Вот примерно подобное. Правда это для дерева
http://catalog.mista.ru/public/538733/

(0) Год назад спрашивал решение похожей проблемы тут: Оптимизация поиска в УФ с большим числом строк. Как в УФ хранить ТЗ только на сервере?
Основная проблема любого поиска на клиенте в том, что пока пользователь не увидел строчки на своём экране, то с большой вероятностью их на клиенте ещё нет. Любой поиск приводит сначала к получению всех строк на клиента (тот самый лаг первого поиска) и потом уже к поиску. Я свою проблему решил храня проиндексированную ТЗ во временном хранилище на сервере и получал номера нужных строк неконтекстным сетевым вызовом.

(23) *неконтекстным серверным вызовом

(23) >>пока пользователь не увидел строчки на своём экране, то с большой вероятностью их на клиенте ещё нет
Мне просто непонятно, если этих данных нет на клиенте, то где они? На сервере, если не тащить туда контекст их тоже нет.

(25) На сервере всё есть. Контекстный вызов как бы "обновляет" данные сервера по последним данным клиента. В теории там вроде как есть оптимизация и на сервер передаются только изменившиеся с последнего вызова данные, но я бы не стал на это сильно надеятся.

(26)Очень мило со стороны 1С ) "Я вам посылку принес, только я ее вам не отдам, потому, что у вас документОв нету".

(27) С другой строноны, если в посылке приехало 18 контейнеров картошки, то для росписи в получения не требуется их предварительно разгружать. Т.е. при открытии документа с 100500 строками форма не висит.

(28)Нет разговоров, когда данные изначально были на сервере и их надо перетащить на клиента. Вот тут нет вопросов. Все верно. Но когда изначально данные есть и имеют смысл только на клиенте.А на сервер должны попадать только в момент записи этих данных в БД, какой смысл гонять за их обработкой на сервер? Особенно если у меня там 100500 строк.

(29) Все данные формы изначально есть на сервере. Клиент нужен чтобы их отрисовать и выполнять простенькие локальные расчёты по локальным данным. При разработке УФ нужно соблюдать баланс, чтобы и на клиента передавать как можно меньше данных, и чтобы при этом клиент мог проводить как можно больше локальных расчётов без лишних обращений к серверу.