| alkomarov84 | Дата: Четверг, 23.11.2023, 05:59 | Сообщение # 1 |
|
Рядовой
Группа: Пользователи
Сообщений: 6
Репутация: 4
Статус: Оффлайн
| Основная претензия у меня к попытке поиска по табличным частям. Поиск в них очень медленный.
При хорошем объеме удаляемых данных эти строки занимают 98% всего времени, что обычно является признаком алгоритма O(n^2).
Поэтому предлагаю вместо поиска по тч использовать заранее подготовленное соответствие.
Вижу, что во многих местах уже появился поиск по соответствиям. Направление верное.
Изменения делал на версии 7.01.3p. Все изменения можно найти по комментариям "mixsture".
---
ПолучитьСоответствиеЕстьВКандидатах я реализовал грязновато - заполняю его прямо перед использованием, хотя, конечно, лучше поддерживать этот индекс синхронно с таблицей УдаляемыеОбъекты. Но делал на скорую руку, поэтому в долгий анализ, где изменяется таблица - не опускался.
|
| |
| |
| tormozit | Дата: Четверг, 23.11.2023, 08:21 | Сообщение # 2 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 6184
Репутация: 156
Статус: Оффлайн
| Хотелось бы сначала понять проблему. А затем уже рассматривать ее решение.
Нужен замер производительности (файл pff) проблемной операции с размерами таблиц в форме.
|
| |
| |
| alkomarov84 | Дата: Четверг, 23.11.2023, 18:55 | Сообщение # 3 |
|
Рядовой
Группа: Пользователи
Сообщений: 6
Репутация: 4
Статус: Оффлайн
| Я сосредоточился на процессе с индикатором "Загрузка ссылающихся объектов". У тебя это делает процедура вПоказатьСсылкиНаУдаляемыйОбъект.
Для удобства замеров я из нее сделал 2 копии:
вПоказатьСсылкиНаУдаляемыйОбъект_Оригинальная - тут только твой код
вПоказатьСсылкиНаУдаляемыйОбъект_Новая - тут с моими изменениями
А вместо тела основной вПоказатьСсылкиНаУдаляемыйОбъект вызываю эти 2 подряд, при этом обрамив их подсчетом времени в милисекундах. Результат пишу в окно сообщений.
Тестировал я так: открываю "Удаление объектов с контролем ссылок", верхняя таблица у меня уже заполнена 25к объектами, отжимаю кнопку "По кандидату", жму Контроль, (запускаю замер в конфигураторе), на вопрос об удалении отвечаю "нет", (после окончания останаливаю замер в конфигураторе), (копирую текст из окна сообщений с временем выполнения каждой процедуры).
В таблицеСсылок (на форме это вкладка Ссылки на кандидата, при отжатой кнопке ПоКандидату они идентичны) у меня 214к строк. В УдаляемыеОбъекты (на форме это таблица сверху) у меня 25к строк.
При наблюдении за индикатором прогресса "Загрузка ссылающихся объектов" у меня сложилось впечатление, что он начинает с высокой скорости обработки (около 400 объектов в секунду),
а затем равномерно снижается до 90/с. Предположу, что каждый раз ему приходится дальше и дальше находить строку в ТЧ, а ищет он банальным перебором с первой до момента найденности.
Учитывая, что один цикл ты уже объявил для перебора СтрокиСсылающихсяОбъектов, которые без отбора по кандидату берутся из ТаблицаСсылок, а затем в каждой итерации просишь найти по табличной части УдаляемыеОбъекты (а это ищет перебором, т.е. по сути циклом) - так и получается цикл в цикле, т.е. O(n^2).
Заменив второй перебор на индексированный поиск по ключу соответствия, должно получиться O(n*logn).
вПоказатьСсылкиНаУдаляемыйОбъект_Оригинальная: 2586779
вПоказатьСсылкиНаУдаляемыйОбъект_Новая: 33629
вПоказатьСсылкиНаУдаляемыйОбъект_Оригинальная: 2308983
вПоказатьСсылкиНаУдаляемыйОбъект_Новая: 35029
(время тут в милисекундах. Как видишь, разница близка к 100-кратной)
Прилагаю также замер из конфигуратора. Обрати внимание, что поиск по тч УдаляемыеОбъекты занял 91% времени, сильно обойдя даже ресурсоемкий платформенный поиск ссылок на объект.
Прилагаю и обработку "Удаление объектов с контролем ссылок", из которой делал замеры, для возможности повторения.
|
| |
| |
| tormozit | Дата: Четверг, 23.11.2023, 20:41 | Сообщение # 4 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 6184
Репутация: 156
Статус: Оффлайн
| Спасибо за подробное обоснование. Создал задачу https://www.hostedredmine.com/issues/975079
Но замечу что при большом числе кандидатов и малом числе ссылок заполнение соответствия будет замедлять работу программы. Поэтому я буду применять его в большинстве, но не во всех случаях.
|
| |
| |
| alkomarov84 | Дата: Четверг, 23.11.2023, 23:27 | Сообщение # 5 |
|
Рядовой
Группа: Пользователи
Сообщений: 6
Репутация: 4
Статус: Оффлайн
| Да, согласен. Обычно для коллекций, измеряемых сотней и меньше элементов - прямой перебор отработает быстрее, чем построение двоичного дерева. Но при переходе к тысячам и далее начинает выигрывать дерево.
Я для себя оставил этот инструмент через дерево, потому что на коллекциях в сотню - замедление очень маленькое и не ощущается, а вот когда на большом объеме это занимает часы - вот это очень сильно мешает работать.
|
| |
| |
| tormozit | Дата: Суббота, 25.11.2023, 14:34 | Сообщение # 6 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 6184
Репутация: 156
Статус: Оффлайн
| Исправлено в 7.02
|
| |
| |
