Конфигурация на базе типовой ТИС..
При загрузке из экселя большого количества новых элементов начинает тормозить.
Структура: Справочник "Номенклатура" и два подчинённых справочника "Цены" и "ЕдиницыИзмерения"
При загрузке используются транзакции, которые фиксируются после каждой 1000 элементов.
После 5000 начинает заметно тормозить и скорость падает.
Замер показывает следующее:

212    Спр.Записать();            75    228.873823    98.98 //Номенклатура, записываем новый элемент
220    СпрЕ.Записать();    76    0.028009    0.01  //Единицы, записываемый новый элемент
223    Спр.Записать()            76    0.015034    0.01  //Номенклатура, обновляем единицы измерения
233    СпрЦ.Записать();    76    0.174291    0.08  //Цены, записываем новый элемент с периодическими реквизитам

Почему так получается и что с этим сделать?

Не пробовал Эксель сначала в ТЗ грузить, а оттуда уже - в справочник?
Мне кажется, долго открытый COM-объект Экселя может ресурсы жрать.

(1) до замера производительности были у меня такие мысли..
но ресурсов вроде не сильно тратится: 3% ЦП и 450м оперативки, причем память не увеличивается.

Делай по 100 элементов

(3) ага.. уже
пока падения скорости обработки не заметно

(3) В транзакции по 100-500 элементов

по 100 элементов в транзакции обрабатывается от 2 до 10 секунд..

гы.. после 11 тысяч скорость упала в 10 раз

10000 2
     10100 2
     10200 2
     10300 1
     10400 2
     10500 1
     10600 2
     10700 2
     10800 1
     10900 1
     11000 1
     11100 41
     11200 20
     11300 37
     11400 54
     11500 72
     11600 68
     11700 43
     11800 60

может у тебя где-то транзакция не закрывается вовремя?

основное время жрется чтением из Экселя если поячеечно читается.
Вруби замер производительности и смотри на колов операций и продолжительность. Тогда можно предметно говорить.

я тоже думал что эксель..
но по замерам показывает что запись нового элемента в справочник
кста.. никакого ускорения не было при транзакции в 100 элементов. просто я в предыдущие разы уже создал 11 тысяч элементов и обработка их просто обновляла, поэтому запись шла быстрее.
а после 11 тысяч начались новые элементы и скорость упала в 10 раз

(9) в (7) пункте количество отработанных элементов и прошедшее время в секундах

кста.. при транзакции по 500 после 13500 элеменнтов 1с вылетела с ошибкой CODEBASE  ERROR Error -70 Reading File SC84.CDX


ну и время в последней обработке росло по экспоненте.. последние 500 элементов 13к секунд, предыдущие 500 - 5к секунд, предыдущие - 700 секунд..

(9) замер производительности в (0).. в экселе читаю построчно если элемент найден обновляю флаг и реквизит подчиненного справочника,
если не найден то создаю новый элемент  справочника" номенклатура", записываю, создаю новые элементы в подчиненных справочниках "единицы" и "цены" и снова записываю элемент "номенклатура"
из замера видно что если записывать новый элемент занимает очень много времени, а если потом его просто записать, то быстро.. строки замера 212 и 223

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

Семерка уже сырая...

(10) ну если совсем плохо будет - скидывай базу мне, я на своем компе попробую прогнать.
и да, запись жрет достаточно много времени. я на обмене КИС-WMS сначала находил эклмент и тупо создавал новый/записывал. А потм переделал на кучу проверко чтобы понять - надо ли обновление делать существующих. и хотя проверко дохрена - все стало летать нааамного быстрее, секунд 10-15 против минут

а вот ошибка -17 - это нехорошо, не нравится мне это...

(0)
Посмотрите 30 сообщение в теме: https://forum.infostart.ru/forum9/topic36308/
"максимальный приемлемый размер ключа для "движка" "1С 7.7" равен 117 байтам"(с)

если база на скуле стоит посмотреть как там фрагментирован лог файл и какими порциями прирастает mdf и ldf
а то бывает там по 1 мб приращение ставят а потом удивляются почему все колом встает на объемных загрузках.

(13) спс..
есть тупое решение. тупо разбить загрузку на несколько.

если я правильно понимаю.. у меня при загрузке тупо растёт индексный файл: от 16 метров до 2 гигов при записи новых элементов.

учитывая тот факт, что десять лет назад у меня таких проблем не было на идентичной базе, то пока проблему я вижу из-за двух местах: ОС или длинные реквизиты.
есть возможность проверить и то, и то..

Если растёт индекс - значит, индексные выражения большие...
Нигде строк длинных проиндексированных нет?

(18) Наименование всегда индексируется и у номенклатуры всяко не 10 длина наименования

(19) У других-то не растёт?

не заметил про cdx файл.
тогда надо смотреть фрагментацию индексов в первую очередь, размер файлов и количество записей в них.

Если растет индекс, значит, неэффективно перестраивается дерево. Значит, большой разнобой в наименованиях. Значит, сортируй предварительно (в екзеле, или выгрузив предварительно в ТЗ) по наименованию.
ну, или сделать прямые создание и запись. Но для разовой задачи это лениво.
Можно не писать наименования, писать только равное ему "ПолноеНаименование", а после загрузки "снаружи" перезаполнить, и штатно переиндексироваться.
Можно посмотреть, какой именно индекс занимает больше места в файле - но я название той утилиты уже не помню. Можно заголовок cdx разобрать, конечно  - но тоже лениво для разовой задачи.

(10) sc84 - это номенклатура в ТиС?
там есть такой прикол - индекс на поле НеВключатьВпрайс
при большом количестве вставок у DBF-движка крышу от этого сносит, и выражается как раз в таком вот росте индексного файла.

(23) а почему именно на это поле? у меня аналогичных флажков несколько, "ассортиент", "выгружать наружу"...

(17) много реквизитов с сортировкой и отбором. и часто увеличивают наименование свыше 50 символов

(24) я так понимаю, что на любое поле с флажком такая реакция. Но нужно чтобы номенклатур были десятки тысяч.
мне один раз попадалась такая база с номенклатурой автозапчастей - для добавления поля в справочник пришлось выключать отбор, а после обновления снова включать.

итого..
достал базу из архива. три штуки.
1. уменьшил наименование со 100 до 50
2. изменил обработку. новый элемент решил попробовать сразу записать с пустым наименованием и реквизитами
3. ничего не менял. но запустил на своем компе вместо сервера. только реиндексировал

в базе наименование строка 100, артикул строка 25 сортировка и отбор, НеВключатьВпрайс число 1 сортировка и отбор

1 вариант загрузил 45к позиций в базу менее чем за 9 минут
2 и 3 вариант.. скорее всего до конца не дойдут.

(0)Проще прямым запросом проинсертить табличку.
В снеговике, тоже шляпа с добавлением новых элементов.
Спонадобилось тут 90 мультов создать элементов с 1 реквизитом наименование. Дык вот, штатненько, можно и неделю лепить.
А так, сам скуль справился минут за 10.

И это с учетом выгребания самих наименований с рс, в котором это наименование как реквизит регистра и количеством неуникальных записей 250 мультов.

ну это...
если наименование сделать длиной 80, то 45к загружает за те же 9 минут

(30) сыми отборы со всех реквизитов и пробуй.

(31) зачем?
в (15) правильный ответ.. если уменьшить длину наименования, то проблема исчезает

ещё один вариант решения..
запускаем обработку, после того как она создала 10к новых элементов прекращаем её по esc. реиндексируем базу(ибо индекс будет около 1 гига, после реиндексации 20 метров)
запускаем обработку снова, первые 10к у нас уже созданы и она их быстро перезапишет и начнёт тормозить уже на второй 10К. повторяем процедуру

(26) флажок-то - это обычный числовой реквизит. длина = 1.
есть мысль что если на флажок (допустимые значения 0/1) поставить длина=2 (учитывая ВОЗМОЖНЫЙ ЗНАК (или поиграться с признаком "неотрицательный" - то ситуация станет лучше)

(12) Восьмёрка ещё сырая, семёрка уже перезрела. Как жыдь?

(35) Можно пилить. Можно трясти. Ещё можно сидеть на берегу реки (говорят, если достаточно долго сидеть, то мимо обязательно проплывёт труп твоего врага).

(36) труп - это EDT..?