Эксперимент заранее не готовился. Ко мне обратились пользователи с вопросом медленной работы (порой зависания) списка справочника "Партнеры". Запустил под собой, проверил - все нормально, никаких зависаний нет. Запустил (на той же машине) под пользователем, который ко мне обратился - действительно список тормозит, причем только при прокрутке стрелками с клавиатуры, но не мышкой. Быстро понял в чем дело - в ПриАктивизацииСтроки происходит получение дополнительной информации по партнеру. Что может быть причиной? Смотрю права - у пользователя назначено более сотни ролей, у меня две (Полные права, Администратор системы). Добавляю пользователю роль "Полные права", проблема остается - список торомозит. Убираю у пользователя все кроме полных прав - проблема торможения списка уходит.
Вывод - большое количество ролей замедляет работу пользователя, что в общем то предсказуемо, но в данном случае подтверждено экспериментально.
Привожу результаты замеров производительности (приведены строки кода и время их выполнения для описываемых выше случаев):
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
0,0149994897959184 - "много" ролей
0,0028094977973568 - "мало" ролей
Время выполнения различается на порядок!
Результат = Запрос.Выполнить();
0,0136426805555556 - "много" ролей
0,0107065418502203 - "мало" ролей
Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока);
0,0107463741496599 - "много" ролей
0,0096472290748899 - "мало" ролей
Из замеров видно, что существенные различия во времени исполнения дает строка кода:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
Разбив строку условия на 2 отдельных условия и замерив время, выяснилось, что критичной является часть условия "Партнер.ЭтоГруппа", что логично, так как здесь происходит обращение к БД. Влияния количества ролей на время выполнения другой части условия - НЕ ЗначениеЗаполнено(Партнер), не выявлено.
На этом эксперимент не закончился. Я решил исследовать характер обнаруженной зависимости.
Далее я вернул пользователю исходные роли, добавил роль "Полные права" и стал последовательно удалять по 20 ролей (роли удалялись подряд по списку, роль "Полные права" не удалялась), делая замеры по строке с наибольшей разницей во времени выполнения на каждом из этапов. Результаты представлены ниже.
Строка кода, по которой проводились замеры:
Если НЕ ЗначениеЗаполнено(Партнер) ИЛИ Партнер.ЭтоГруппа Тогда
Результаты замеров представлены на графике:
Из графика видно, что, с учетом неизбежных погрешностей измерений, зависимость линейная.
Выявив характер зависимости, нужно было устранить влияние данного кода на работу списка.
Для этого код был выделен в отдельную процедуру, а в "ПриАктивацииСтроки" вместо него добавлен вызов обработчика ожидания:
&НаКлиенте
Процедура СписокПриАктивизацииСтроки(Элемент)
ПодключитьОбработчикОжидания("ВывестиДопИнфоПоПартнеру",0.2,Истина);
КонецПроцедуры
&НаКлиенте
Процедура ВывестиДопИнфоПоПартнеру()
Контакты = ***КлиентСервер.ПолучитьДопИнфПоПартнеру(Элементы.Список.ТекущаяСтрока);
КонецПроцедуры
Таким образом влияние времени выполнения данного кода на скорость прокрутки списка было исключено.
Это решение подсказано в комментариях к начальной версии данной публикации участником nixel , за что ему огромное спасибо.
Данная публикация является логическим продолжением другой моей публикации, связанной со скоростью работы списков -
УТ 11: Ускоряем форму подбора номенклатуры , в которой предлагается решение вопроса ускорения работы списка путем изменения его запроса. Но, как выясняется, проблема может лежать и в совершенно другой плоскости.
Спасибо всем, кто высказал дельные замечания в комментариях, что позволило дополнить публикацию.
P.S.
26/03/2021
Проблема до сих пор не решена, рекомендую ознакомиться с публикацией //infostart.ru/1c/articles/1409398/, посвященной проблемам производительности, в ней влияние количества ролей на производительность описано в разделе "Первая проблема".
