Удаление строк из таблицы значений различными способами с замером производительности

09.01.24

База данных - HighLoad оптимизация

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

Скачать исходный код

Наименование Файл Версия Размер
Удаление строк из таблицы значений различными способами с замером производительности:
.epf 9,36Kb
25
.epf 9,36Kb 25 Скачать бесплатно

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

Изначально мы рассматривали только два варианта реализации, но я решил рассмотреть все варианты, какие только могли прийти в голову. Результаты в конце, код обработки отдельно под спойлером.

 

Описание вариантов:

 

1. Через запрос. Обрабатываемую ТЗ передаём через параметр в запрос, где применяем нужные отборы, и выгружаем результат запроса в ТЗ.

 
 Реализация варианта с запросом

 

2. Удаление строк. Создаём массив. В цикле обходим ТЗ, проверяя для каждой строки условие, и помещаем строки на удаление в массив. Далее обходим массив строк на удаление и вызываем ТЗ.Удалить(), передавая в него строку из массива

 
  Реализация варианта с удалением строк

 

3. Копирование таблицы. Вариант похож на предыдущий. В начале создаём массив, обходим ТЗ и закидываем в массив подходящие строки. Далее выгружаем нужные строки через метод ТЗ.Скопировать(), передав в него массив нужных строк

 
  Реализация варианта с копированием таблицы

 

4. Копирование строк. Мы создаём пустую копию исходной таблицы. Далее обходим в цикле все строки, выполняем проверку и добавляем в пустую копию подходящие строки.

 
 Реализация варианта с копированием строк

 

5. Предобработка и выгрузка с отбором. Добавляем в ТЗ колонку с типом булево для хранения результата проверки всех условий. Обходим строки в цикле и заполняем её. Делаем выгрузку с отбором по структуре, после чего удаляем новую колонку.

 
 Реализация варианта с предобработкой и выгрузкой

 

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

 
 Реализация варианта с выгрузкой строк

 

 

Способ замера производительности

Замеры выполнял на платформе 8.3.23.1865, SQL 2019.

Замерять я решил на разных объёмах данных (разное количество строк и колонок), с разным процентом удаляемых строк. Причем удаляемые строки я распределил равномерно по всей таблице.

 
 Пример таблицы

 

Для удобства я добавил таблицу со сценарием замеров, в которой перед запуском прописывал варианты количества строк, колонок и количество удаляемых строк. Для быстрого заполнения нужных мне сценариев добавил кнопку.

 
 Скрин

 

Количество строк брал от 100 до 1000000

Количество удаляемых строк брал в размере 2%, 50% и 98% от общего количества строк в таблице

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

Результаты замеров заносил в таблицу.

 
 Код модуля обработки

 

 

Результаты замеров

Ниже приведены результаты для таблиц с уникальными значениями в каждой ячейке. Тестировал для таблиц с 5 колонками и с 50 колонками с разным количеством строк и процентом удаления.

 

Для начала сравним время выполнения при 2% удаляемых строк.

 
 График 2%

Из графика видно, что дольше всех отрабатывают два способа: Запрос (1) и копирование строк (4). На небольших объёмах данных отличие незначительно, но на таблицах 1 млн строк Запрос (1) отрабатывает чуть быстрее.

Однако, при увеличении количества колонок результаты меняются: Запрос (1) начинает существенно проигрывать копированию строк (4).

В обоих случаях способ с удалением строк (2) оказывается самым быстрым. А при большом количестве колонок он даже опережает выгрузку с отбором (6).

Вывод: Если ожидается малый процент удаления строк, то самым оптимальным будет способ Удаление строк (2). Причем на любом объёме данных и при любом количестве колонок.

 

Удаление 50% строк

 
 График 50%

Удаление строк (2) дольше всего отрабатывает на любом количестве строк при маленьком количестве колонок. Быстрее всего отрабатывают Копирование ТЗ (3) и Предобработка с выгрузкой (5).

Запрос (1) работает в разы дольше остальных способов при большом количестве колонок. Удаление строк (2) в этом случае наоборот выполняется быстрее всех. Хотя, производительность Удаления строк (2) не на много больше чем у Копирования ТЗ (3) или Предобработки с выгрузкой (5).

Выгрузка ТЗ с отбором (6) здесь выигрывает при любых параметрах таблицы.

Вывод: При ожидаемом удалении примерно половины строк лучше всего подойдёт Копирование ТЗ (3) или Предобработка с выгрузкой (5). Для таблиц с большим количеством колонок можно использовать Удаление строк (2).

 

Удаление 98% строк

 
 График 98%

Как видно из графиков, самые неоптимальные способы - Запрос (1) и Удаление строк (2) (Запрос хуже отрабатывает при большом количестве колонок). Копирование ТЗ (3) отрабатывает быстрее всего при любом количестве колонок.

Вывод: Если ожидается большой процент удаления, оптимальнее всего использовать (3) Копирование ТЗ. Также близки по производительности Предобработка с выгрузкой (5) и Копирование строк (4).

 

Итог

При проектировании правильнее всего ориентироваться на процент удаления строк.

1. Запрос. Самый долгий способ отбора строк. Годится только если колонок не много или для отбора требуется использовать какие-то возможности запроса (соединения с другими таблицами, сортировку итоговой таблицы и т.п.).

2. Удаление строк. Оптимален если заранее известно что требуется удалять меньшую часть строк, или таблица состоит из большого количества колонок.

3. Копирование таблицы. Самый универсальный способ удаления. Особенно хорошо использовать при среднем или большом проценте удаления.

4. Копирование строк. Годится только при большом проценте удаления и с небольшим количеством колонок.

5. Предобработка и выгрузка с отбором. Результаты схожи с Копированием таблицы (3). Зато очень удобно для отладки.

6. Выгрузка с отбором. Это самый быстрый способ, но, к сожалению, он не всегда применим.

 

 
 Влияние уникальности значений в ячейках (бонус)

Как вы могли заметить, на форме обработки тестирования есть галка Заполнять уникальные значения в каждой строке. Гораздо быстрее при формировании таблицы заполнять все строки одинаковыми значениями. Но, я решил провести эксперимент.

Так выглядит тестовая таблица с уникальными значениями:

А так с одинаковыми:

И вот результат прогона тестовых таблиц одинакового размера (10 колонок 100.000 строк, 50% удаления):

Как видно из результата замера, все тесты с неуникальными значениями в ячейках выполняются чуть дольше. Особенно это заметно в варианте Запрос (1).

 

Проверено на следующих конфигурациях и релизах:

  • 1С:ERP Управление предприятием 2, релизы 2.5.12.73

ТаблицаЗначений; Удалить Удаление Запрос Перебор Замер Скорость Поиск

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    3828    spyke    28    

47

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5850    vasilev2015    19    

39

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    8912    175    ZAOSTG    74    

104

Переход на Clickhouse для анализа метрик

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    3786    glassman    17    

38

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    10027    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5619    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    17009    skovpin_sa    14    

102
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. doom2good 139 08.01.24 21:57 Сейчас в теме
Прикрепляю результаты замеров и обработку
Прикрепленные файлы:
Замеры 2024.01.05.xlsx
user822247; +1 Ответить
18. doom2good 139 09.01.24 18:08 Сейчас в теме
(1) куда-то обработка пропала
Прикрепленные файлы:
ТестСкоростиУдаления3.epf
2. Hitcher 172 09.01.24 09:30 Сейчас в теме
Мои 5 копеек после прочтения
1. Есть еще такой механизм как ПостроительЗапроса, с помощью которого можно отобрать строки в таблице значений.
2. Есть мнение, что если нужно отобрать по данным БД (типа Номенклатура.Код > 1000 и Контрагент.Регион В (&МассивРегионов) ) то лидеры будут совсем другие.
5. doom2good 139 09.01.24 11:24 Сейчас в теме
(2)
1. Есть еще такой механизм как ПостроительЗапроса, с помощью которого можно отобрать строки в таблице значений.

Пришлите пожалуйста код, я не работал с ним. Это не будет то же что и запрос по производительности?

(2)
2. Есть мнение, что если нужно отобрать по данным БД (типа Номенклатура.Код > 1000 и Контрагент.Регион В (&МассивРегионов) ) то лидеры будут совсем другие.

Согласен. Я это преимущество тоже отметил в итогах. Но, здесь сравнивал именно скорость удаления строк.
3. Xershi 1490 09.01.24 11:07 Сейчас в теме
2. Нужно переписать чтобы обход был с конца и удалять строку сразу без массива!
Он точно удалит правильные строки? Или индекс съедет и после удаления первой строки удалится не вторая, а третья?
Swappy; van_za; Oliver; SerVer1C; +4 Ответить
4. doom2good 139 09.01.24 11:19 Сейчас в теме
(3) если обходить с конца, будет незначительный выигрыш по памяти т.к. не придётся хранить массив строк. Самое долгое в этом способе - само удаление.
По производительности какие-то крохи даст отказ от лишнего обхода массива. Если правильно понимаю, при оценке алгоритмической сложности это вообще не учитывается.
Но, спасибо за идею. Будет время - проведу сравнение обоих способов. Уверен, ваш будет чуть быстрее, процентов на 5.
17. Xershi 1490 09.01.24 18:06 Сейчас в теме
(4) где-то на форуме даже свежий код кидал с красивым удалением.
Когда обход таблицы на клиенте, а удаление на сервере. Это важно.
7. SerVer1C 775 09.01.24 13:14 Сейчас в теме
(3) Всегда удаляю так:
Для й = 1 - ТЗ.Количество() По 0 Цикл
	
	Если ТЗ[-й].Удалить Тогда // Здесь должно быть сложное условие типа: ТЗ[-й].Сумма = 0 И ТЗ[-й].Контрагент = КонтрагентВася
		ТЗ.Удалить(-й);
	КонецЕсли;
	
КонецЦикла;
Swappy; PersianovMS; RustIG; skeptik2105; Istur; kalyaka; Strobe; +7 Ответить
29. RustIG 1631 10.01.24 19:54 Сейчас в теме
(7) это конечно самый простой случай вы рассмотрели. Обратите внимание на замечание Славы Крон (28). В общем случае, сначала идет обработка Тз в цикле (с использованием индексов или без зависит от задачи) и выделяются (запоминаются) строки Тз для удаления. Обычно достаточно в массив запомнить. Далее обход массива с непосредственным удалением строк Тз - лучше делать с конца, чтобы индексы Тз быстрее перестраивались.
30. SerVer1C 775 10.01.24 23:06 Сейчас в теме
(29) Не понял про простой случай. Приведенный выше код отработает всегда. В нем идет удаление строк с конца. Здесь не надо 2 раза гонять цикл и не надо задействовать дополнительную память. Понятно, что эти оптимизации не особо влияют на производительность в 1С, но в ТРУ ЯВУ это будет заметно.
starik-2005; +1 Ответить
31. RustIG 1631 10.01.24 23:31 Сейчас в теме
(30) ваш код прекрасен, но для простых случаев - когда ТЗ уже обработана и готова к удалению строк по какому-либо условию.
Вот у меня сейчас решается задача - там три цикла по ТЗ. И оптимизировать в моем случае надо "анализ и обработку" ТЗ в первых двух циклах (в которых вложены еще циклы), где я собираю ТЗ из разных ТЗ, группирую по колонкам, и т.д. - а не оптимизировать само удаление строк, хотя оно и присутствует у меня третьим циклом.
Я постараюсь замерить разницу вашего кода и своего классического удаления "лишних" строк. Но, думаю, что само удаление составит 1% времени от всего алгоритма, и оптимизировать 1% до еще 0,5% не хочется.

Другой пример - обработка строк происходит в цикле, вложенном в другой цикл. Или ТЗ рекурентно передается в функцию для анализа строк. Сразу удалять строки из ТЗ никак нельзя. А вот запомнить в отдельный массив - пожалуйста.
Или не?
32. SerVer1C 775 10.01.24 23:37 Сейчас в теме
(31) Оптимизации - это уже тема другого разговора. А в вашем случае обходите ТЗ "снизу". Ничего же не мешает вам сразу удалить строку, а не запоминать указатель на строку в отдельной структуре хранения данных.
33. RustIG 1631 10.01.24 23:57 Сейчас в теме
(32) задача удалить строки из ТЗ, состоящая из 10 тыс. строк - выдуманная. В ней ваш метод рабочий.
В реальных задачах вы ТЗ много раз обработаете "цикл в цикле" или рекурентно (например, для классических задач динамического программирования или задач с деревьями и графами).
В последних задачах как раз и нужно
запоминать указатель на строку в отдельной структуре хранения данных

Или еще не?
34. SerVer1C 775 11.01.24 00:02 Сейчас в теме
(33) я не спорю, что могут быть алгоритмы, в которых сначала находится строка для удаления, условно, из середины, потом из начала, потом из конца... Тогда тут никак не обойтись без промежуточной структуры данных, которую придется упорядочить перед непосредственным удалением строк. Всё же в публикации рассматриваются академические способы удаления и их скорости.
38. RustIG 1631 11.01.24 11:11 Сейчас в теме
(34) забрал ваш алгоритм в свою разработку.
lsg45; SerVer1C; +2 Ответить
42. CheBurator 3122 15.01.24 01:45 Сейчас в теме
(33)
рекурентно

возможно, ты спутал "рекурентный" и "рекурсивный"...
43. CheBurator 3122 15.01.24 01:48 Сейчас в теме
(33)
задача удалить строки из ТЗ, состоящая из 10 тыс. строк - выдуманная.

- фигня какая ;-)
не далее как пару дней назад - ТЗ порядка 50 тысяч строк, из них удаляется около 7000 (или 17000? не помню уже ) строк с "кривыми" данными... вполне себе прикладной рабочий проект, Заказчик сует в прогу кривые данные и потому вопросы почему в алярм выпадает ...
44. RustIG 1631 15.01.24 10:11 Сейчас в теме
(43) Сергей, я понимаю о чем вы хотите сказать...
вы вырываете из контекста дискуссии мою фразу....
"удалить из ТЗ , состоящей из 10 тыс строк" - это правда выдуманная задача.
В контексте дискуссии фраза относится к изначальной постановке задачи и тестам улучшить и/или оптимизировать простое удаление строк...
Я же уже написал , что надо в комплексе смотреть на решение другой большой задачи, в которой удаление строк из ТЗ является лишь маленькой подзадачей .
Реально здесь только то, что есть реальные задачи, в которых приходится оперировать ТЗ, состоящими из 10 и более тыс строк. Удаление лишних строк является лишь подзадачей, но не главной задачей, и тем более не самой затратной по времени выполнения.
В моей последней работе тоже ТЗ - там более 100 тыс строк и удаление строк всегда меньше или равно половине строк ТЗ - то есть почти каждая вторая проверяется и удаляется.
В связи с тем, что в большой задаче возникает ТЗ, надо оптимизировать удаление строк ТЗ уже на этапе формирования самой ТЗ...
47. CheBurator 3122 15.01.24 11:01 Сейчас в теме
(44) ясен пень про "на этапе формирования ТЗ", но кто ж вперед смотрит когда костяк пишет? ;-) Времени почти всегда столько что продумать отрисовать и прогнать схему вчерновую и только потом нормально закодить - фиг вам, а не достаточно времени ;-) Я вот писал последний код (в клюшках конечно, но сути не меняет) - думаешь я там сильно над оптимизацией думал? ага, как-же, дидлайн на горизонте и все ближе. Поэтому писал быстро и стопудово рабоче. А то что оказалось в ряде моментов медленно в продакшене - се ля ви как говорится...
45. RustIG 1631 15.01.24 10:21 Сейчас в теме
(42) :)))))))))
как-то не думал,
всегда разделял, что в программировании используем "рекурсивные процедуры и функции", но если речь об "общем" соотношении

В реальных задачах вы ТЗ много раз обработаете "цикл в цикле" или рекурентно


то используем именно слово "рекурентно"

Видимо, сильно влияние книг по математике, которые я в последние годы читаю...Там это слово часто звучит...
Как -то само это слово вырвалось у меня из головы...
46. RustIG 1631 15.01.24 10:53 Сейчас в теме
(43) у меня в недавних статьях есть АВС распределение
реализовано на табл. части внешней обработки - уже не помню точно
но кажется была проблема сохранить распределение в табл. часть документа - потому что в документе есть огран. на кол-во строк ТабЧасти =99999
Во внешней обработке таких огран. нет вроде.
Так вот при тестах самая долгая операция была прохождение табл. части по циклу - чтобы что-то там посчитать...А циклов в алгоритме около 4 - это только для двух показателей. В общем, удалось ускорить процесс в разы только за счет того, что часть расчетов со строками табл. части производится до заполнения табл. части - в запросе. Запрос быстрее считает общие итоги по строкам, коэффициенты по каждой строке.
Хотя классический вариант алгоритма - который везде описан - именно такой, что надо считать итоговые суммы и коэффициент по строке в момент обхода строки в цикле...Что в 1с затратно...
Алгоритмы - вещь такая....написано одно, делаем по своему
6. markers 275 09.01.24 13:03 Сейчас в теме
Ещё интересно влияние на процесс индексов
10. doom2good 139 09.01.24 13:52 Сейчас в теме
(6) в плане - будет ли дольше работать если таблица проиндексирована?
11. markers 275 09.01.24 13:55 Сейчас в теме
(10) С одной стороны индексы ТЗ наверное могут дать буст (особенно конечно при выгрузках), с другой стороны ей придется удалять строку из индекса, по этому и интересно, будет ли разница и в какую сторону.
12. doom2good 139 09.01.24 13:58 Сейчас в теме
(11) Выгрузка используется только в 5 и 6 способах. 6 не рассматриваем т.к. он чисто справочно приведён (там, понятно, индекс поможет). А в 5 случае мы выгружаем по колонке с типом булево. Индекс булевой колонки не даст прироста производительности, на сколько мне известно.
8. RocKeR_13 1329 09.01.24 13:37 Сейчас в теме
Тут, как мне кажется, есть нюанс. Если мы обрабатываем абстрактную таблицу значений, то замечаний никаких: мы можем как создать копию исходной таблицы с нужными строками, так и удалить из существующей строки. Но довольно часто встает задача удалить строки из табличной части (документа/справочника/обработки и т.д.). Вот тут как раз и кроется нюанс: если мы выгружаем данные в новую таблицу значений, то ее потом нужно будет обратно загрузить в табличную часть в отличие от "классического" варианта "2. Удаление строк". В случае небольшого общего количества строк загрузка в табличную часть, скорее всего, заметного прироста к общему времени не даст. А вот что будет на большом количестве - вопрос открытый.

У меня как раз сейчас задача по загрузке данных из сторонней БД (загрузка происходит в обработке) с предпросмотром для пользователя; после загрузки есть постобработка, которая подразумевает удаление некоторого количества строк. Сам замерять так и не стал - пошел по пути "складирования" удаляемых строк в массив с последующим удалением строк при обходе подготовленного массива, так как количество удаляемых строк мало (буквально 5-10) при относительно большом количестве строк (около 2 тыс.). Колонок около 15.
9. doom2good 139 09.01.24 13:51 Сейчас в теме
(8)
пошел по пути "складирования" удаляемых строк в массив с последующим удалением строк при обходе подготовленного массива, так как количество удаляемых строк мало (буквально 5-10) при относительно большом количестве строк (около 2 тыс.). Колонок около 15.
Это самый оптимальный вариант в таком случае. Выгрузка-загрузка, думаю, займёт больше времени.
13. RocKeR_13 1329 09.01.24 14:09 Сейчас в теме
(9) В данном конкретном случае тоже так думаю.
14. milkers 2877 09.01.24 14:10 Сейчас в теме
10. Я может не внимательно читал, но я нигде не нашел использования механизма индексации.
Что в запросах, что в таблицах. На больших таблицах это должно изменить все измерения.
SagittariusA; RustIG; +2 Ответить
15. doom2good 139 09.01.24 15:37 Сейчас в теме
(14) про индексацию отвечал в сообщении (10)
А вообще, это тема для отдельного замера
16. milkers 2877 09.01.24 15:48 Сейчас в теме
(15) Рекомендую с ними поторопиться или пока снять статью с публикации. Знаю здешнюю аудиторию, могут наставить минусов. Дело в том, что на маленьких таблицах оптимизация не играет большой роли, а на больших без индексации не обойтись.
19. John_d 5440 09.01.24 22:32 Сейчас в теме
Интересно было бы посмотреть на сравнительный замер, если массив перевести в json и передать в JavaScript с методом filter()
https://infostart.ru/1c/articles/1355214/
22. smit1c 106 10.01.24 09:19 Сейчас в теме
(20) Всё новое - это хорошо удалённое старое 😁
24. shard 279 10.01.24 13:48 Сейчас в теме
(20) история сделала еще один виток) https://infostart.ru/1c/articles/57376/
Подход обстоятельный, любопытно почитать.
48. artbear 1547 17.01.24 17:23 Сейчас в теме
21. genayo 10.01.24 06:31 Сейчас в теме
А ещё результаты могут зависить от версии и разрядности платформы, и от операционной системы
23. tormozit 7160 10.01.24 12:02 Сейчас в теме
Удаление строк из таблицы подразумевает сохранение всех указателей на оставшиеся строки. Поэтому все способы, кроме непосредственно удаления, не подходят для решения задачи. Нужно правильнее будет изменить заголовок статьи на "Получение таблицы без отобранных строк..."
Tavalik; SerVer1C; +2 Ответить
25. amiralnar 9 10.01.24 14:06 Сейчас в теме
(23) Извините, а что означает "подразумевает сохранение всех указателей на оставшиеся строки"?
26. tormozit 7160 10.01.24 14:22 Сейчас в теме
(25) Указатель на строку таблицы создает так
Стр1 = Таблица[23];
27. amiralnar 9 10.01.24 16:43 Сейчас в теме
(26) Для меня вы говорите загадками. Но кажется я понял о чём вы хотите сказать.
"подразумевает сохранение всех указателей на оставшиеся строки" для случая, когда перед удалением строк таблицы в других местах использовались и сохранились указатели на строки этой таблицы.
39. truba 11.01.24 14:30 Сейчас в теме
По хорошему понять бы каким объектом представлена в 1С коллекция строк таблицы значений. Если связанный список, то применять оптимальную логику для этого объекта. А методы копирования ТЗ очень сильно зависят от содержания самих, объем которых может быть велик.
28. SlavaKron 10.01.24 18:06 Сейчас в теме
Сравниваете несравниваемое – чаще всего, массив удаляемых строк не может быть получен простым отбором, в противном случае, такой отбор (в широком смысле) можно было бы применить ещё на этапе формирования ТЗ. Поэтому считаю каноничным способ удаления через массив строк, т.к. он сохраняет логичность и стройность кода.
glassman; SagittariusA; RustIG; +3 Ответить
35. Tavalik 3366 11.01.24 06:38 Сейчас в теме
Интересный эксперимент. Проделана качественная работа. Спасибо.

Правда, как уже выше писали, иногда необходимо сохранить указатели на строки ТЗ, так что копирование ТЗ не подходит. Но это нечастый случай.
36. Hitcher 172 11.01.24 09:31 Сейчас в теме
(5) Примерная схема отбора такая

ПостроительЗапроса = Новый ПостроительЗапроса;
ПостроительЗапроса.ИсточникДанных = Новый ОписаниеИсточникаДанных(ТаблицаЗначений);

// Простой отбор на равенство
НовыйОтбор = ПостроительЗапроса.Отбор.Добавить(ИмяОтбора);
НовыйОтбор.Установить(ЗначениеОтбора);


//Если нужен сложный отбор
НовыйОтбор = ПостроительЗапроса.Отбор.Добавить(ИмяОтбора);
НовыйОтбор.Использование = Истина;
НовыйОтбор.ВидСравнения = ВидСравнения;
НовыйОтбор.Значение = ЗначениеОтбора;

Результат = ПостроительЗапроса.Результат;

Отборы можно складывать по условию "И".

А будет ли выигрыш по сравнению с запросом? Это вот тема исследования для пытливых умов. Какой из этих двух методов более быстрый?
37. doom2good 139 11.01.24 09:39 Сейчас в теме
(36) Спасибо. Проведу замер, обновлю данные
41. CheBurator 3122 15.01.24 01:41 Сейчас в теме
А где вариант - пробежали по ТЗ. Вычислили условие,
Сделали ТЗ.НадоУдалить = 1; или ТЗ.НадоУдалить = 0; (суммируя счетчик удаляемых строк)
Далее ТЗ.Сортировать("НадоУдалить+"); и проходом с конца ТЗ к началу удалить строку пока счетик удаляемых строк не ноль
?
(или выгрузить/скопировать в другую ТЗ с 1-ой по ТЗ.Количество()-СчетчикУдаляемых)?
.
Интересно, в 8-ке можно ТЗ выгрузить/скопировать частично в саму себя?
49. sbkeg 22.04.24 08:09 Сейчас в теме
Если в замер включается работа с запросом, тогда стоит уточнить, какая СУБД используется? Это ведь самый важный момент для такого способа.
Судя по результатам, у вас вообще файловая ИБ. Но лично у меня, любая обработка данных запросом (если такое возможно) - всегда быстрее, чем использование кода 1С. У меня система работает на MS SQL Server.
Обратите внимание - когда перебираете строки таблицы значений, получение строки с бОльшим индексом занимает больше времени. Из-за этого время получения строк растет не линейно. Т.е. перебор таблицы из 10К строк и 1М строк - разница будет не в 100 раз, а больше. И она будет увеличиваться с увеличением количества строк в таблице. Из этого следует, что количество колонок не имеет такого большого значения, как количество строк.
Для запроса же, при увеличении количества строк время растет линейно. Да и вообще, по рекомендациям фирмы 1С, если есть возможность переложить работу на СУБД - надо так и делать. Это дает более гарантированный по времени результат и снижает нагрузку с кластера 1С, мощность которого всегда ниже, чем мощность СУБД.
К тому же, при получении результата запроса, часто можно обойтись выборкой, без выгрузки в ТЗ. Но я понимаю, что ваша статья не про это).
Оставьте свое сообщение