Создаю 20 тысяч элементов справочника.
Процесс занимает около 4 минут. Можно ускорить?
&НаСервере
Процедура СоздатьЭлементыСправочника(МассивЛС)
    Для Каждого ЛС из МассивЛС Цикл
        Если ЛС[0] = Неопределено Тогда
            Продолжить;
        КонецЕсли;
        Элемент = Справочники.СписокЛС.СоздатьЭлемент();
        Элемент.Наименование = ЛС[0];
        Элемент.НомерПП = ЛС[0];
        Элемент.ЛС = ЛС[1];
        Элемент.Адрес = ЛС[2];
        Элемент.Площадь = ЛС[3];
        Элемент.Проживающих = ЛС[4];
        Элемент.ЗадолжностьНач = ЛС[5];
        Элемент.Начислено = ЛС[6];
        Элемент.Оплачено = ЛС[8];
        Элемент.ЗадолженностьКон = ЛС[9];
        Элемент.СрокЗадолж = ЛС[10];
        Элемент.Записать();
    КонецЦикла;
КонецПроцедуры

Файловая? В транзакции попробуй

Файловая..

А как в транзакции??

Вот вам пажалста - в языке без типизации - что "скрывается" за .адрес? Может строка, а может ссылочный тип, за которым надо лезть в базу?

НачатьТранзакцию() / ЗафкисироватьТранзакцию()
И счётчик, сколько элементов в одной транзакции.
Значением счётчика - поиграться, сколько будет оптимально, это сильно зависит от твоей базы

(4) Зачем за ним лезть?

(1) Понял. Спасибо, БОльшое!

(7) Ты сначала попробуй, сделай...
А спасибать будешь, когда работать нормально будет...

Щас попробую..

А удалять быстро тоже так же??

практика показывает, что серверная быстрее всех отрабатывает на 10к элементах. файловая хз

(11) Спасибо!

(11) А если в каждом элементе 100500 реквизитов? И от сервера зависит...

Насколько я помню, в стандартных конфах или 100 или 1000 элементов в транзакции, не больше.

зачем транзакция?

(15) Чтобы одна блокировка, а не на каждый элемент заново.

(0) как часто ты эти элементы создаешь?

(16) в 77 файловой был ещё прикол, что всё в транзакции держалось в памяти и только при коммите писалось в файлы...

(16) что за одна блокировка? что-то новое
можно немного теории

(17) - раз 5 в день.

(19) Каждое обращение в базу открывает свою транзакцию, если мы явно открыли транзакцию, то следующие обращения в базу идут без необходимости открытия транзакции (и коммита изменений после каждой записи).

Проверил. В транзакции работает быстрее раза в два.

(20) 100т. элементов в день?
зачем такое?

(23) тестируем, пробуем всякие вещи.

(21) про блокировки ты не сказал

у транзакции другое назначение
общая рекомендация - делать транзакции как можно быстрее, как можно меньше элементов изменять в одной транзакции
в данном случае тр-я не нужна

(26) а что нужно тогда?

(27) расскажи, что ты делаешь такого, создавая 100т. элементов  в день?

(18) в 77 там да, летало все

(28) Просто экспериментирую. Учусь.

(30) если пример из головы и не имеет отношения к реальной ситуации, то тут сложно сказать 4 минуты быстро это или медленно
вот если бы тебе заказчик сказал - меня это не устраивает, мне нужно не 4 минуты, а 2, тогда можно было думать

(25) Так блокировки тоже устанавливаются в процессе работы транзакции, а снимаются не после записи, а после подтверждения транзакции.

Я предполагал, есть более быстрый метод. Известный, который не надо выдумывать. Транзакции кстати мне помогли. В 2 раза быстрее примерно работает.

(32) Вроде как да.

На то они и транзакции, чтобы установить блокировки.

(33) мне кажется, в твоем случае нужно не вопрос скорости решать, а начать с самой задачи
вот ты пишешь, что учишься
но какую задачу ты решаешь?

(32) не вижу связи со скоростью записи и с тем, что ты сказал в (15)

в (16)

(38) У вас или каждый элемент блокируется, открывается транзакция, производится запись, подтверждается транзакция и разблокируется элемент.
В транзакции, два первых действия - в начале транзакции, а два последних - в конце.

(39) соглашусь, что может быть прирост скорости засчет меньшего числа коммитов, но не вижу, что блокировок становится меньше или больше
и соглашусь, что может быть в особых ситуациях стоит писать пачками, но тут пока неясно

(40) Блокировок становится как раз больше, так как они не отпускаются, а вот COMMIT - только один.

(41) я к тому, что общее число блокировок не меняется
при большой транзакции они удерживаются до ее конца, но не вижу причин, чтобы именно это уменьшало время записи

(42) В sql-варианте время тратится на открытие и закрытие транзакции, а в файловом - блокируется вся таблица - остальные попытки записи уже не требуют никаких блокировок - именно из-за этого на файловой базе будет прирост скорости больше, чем на SQL.

(43) файловая возможно
тогда тем более не надо так делать - если блокируется вся таблица

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

(45) я говорю, нужно понять задачу
неясно, что у него там за справочник, кто там еще пишет
тут можно много размышлять

(46) Если база тестовая - то пишет в один поток - так что - блокировка всей таблицы ничего страшного не принесёт, а скорость увеличит сильно.

(47) тебе так важно быть правым, не поняв задачи?)

(48) Я говорю, что транзакция обычно ускоряет работу - а прав я или нет - автор проверит сам, если не верит.
Просто, если два процесса одновременно будут создавать элементы (а такая реализация тоже имеет право на жизнь), то транзакция, наоборот, навредит.

(49) ну вот оговорку сделал, уже шаг вперед)

(0)Потомуштааа в 1С нет DML .  Доступен только  Select

и кроме как insert  в 20 0000 цикле вам ничего не доступно  для справочника

(51) При перестроении конфигурации не только SELECT работает, а вот при работе - поменять структуру объекта нельзя - просто - если бы можно было, то это была бы уже не 1С.
(50) Я, например, до конца не знаю, что происходит внутри SQL-сервера, и думаю, что очень мало людей это знают до конца.

(52) Ты ещё скажи, что хранимку написать, чтобы она всё сделала - мечтать не вредно.

(53) вызывается 20 000 insert....  я же написал. Для справочника это единтсвенный путь записи. Новый элемент - новая команда вставки

и причем здесь хранимки....

и причем здесь перестроение конфы ... :)

(56) Ну, можно одну "хранимку", которая внутри сделает 20000 insert-ов, но это будет внутри сервера выполняться.

НачатьТранзакцию
ЗафиксироватьТранзакцию

(57) Хотя, некоторые SQL-сервера поддерживают multi-insert, но один insert на 20 тыс.записей - это будет выглядеть очень интересно.

(60) bulk insert

(61) Ну, там же отката транзакции нет ?

(62) мммм... Только пачкой. Или всё, или ничего

(60) Да фигня. Вставка куска 20 тыс. из одной таблицы в другую, таким еще на 2000 баловались. Все это быстро делается.

(6)
Г-н 1С-ник не знает, что такое lazy loading? У него "как всегда" всё за-бес-плат-на?

(65) а можно все таки ответ на вопрос из (6)
зачем за ссылочным типом лезть в базу?

(36)У него одна задача - поэкспериментировать )) "раз 5 в день".

(65) Г-н 1С-ник знает.
Но совершенно в душе не ***т, причём тут это в данном случае

Можно фунцайку набросать для вычисления оптимального количества элементов на транзакцию.Например, начали со 100 элементов на транзакцию - померяли время. С шагом 50, например, увеличиваем количество элементов и меряем. Стало хуже - уменьшаем количество элементов.

(69) Ну, начинаем со 100 и плюс 100 пока не стало медленнее, а потом дихотомией до нужного значения - только может оказаться, что интервалы занимают различное время работы.

может попробовать хранить данные в РС и записывать данные наборами. Побыстрее должно шуршать.

(71) В принципе, большой разницы не должно быть - только время на создание ГУИД-ов не нужно тратить.

(66) а откуда вы возьмете ссылку? Из базы

(73) для программного кода в (0) какая разница какого типа элементы массива? вы хотите сказать, что при использовании ссылки будет дополнительное обращение к серверу?

(73) ссылка УЖЕ есть.

(74) вы не поняли, ссылки вообще нет. И взять ее неоткуда. Только в базе искать. Например, по наименованию.

(76) Это на потолке написано?

(72) Я подразумевал, что запись пройдет одним запросов вместо 20тыс запросов

(78) Тогда вообще лучше табличную часть справочника - чтобы и чтение тоже за один присест шло ^_^

Параллельно в фоновых задачах. сделай регистр, а потом фоновыми задачами создавай элементы частями.

О, в (71) уже говорили

(14) логично, много не надо. 1 или 100 элементов даст прирост в скорости, а 100 или 10000 разница будет незаметна

(14) а можно поподробнее где это в "стандартных конфах"?
что за операция?

(83) ну, самая главная обработка

УниверсальныйОбменДаннымиXML

которая используется везде и всюду.

20 000 за 4 минуты??? на файловой? да ты летаешь.

(85) файловая работает медленнее SQL?

(85) По моему опыту маленькая 1-2 гб база в файловой на запись работает существенно быстрее серверной на одинаковом железе

(87)так и есть, неоднократно уже обсасывали, статья даже есть по этому поводу http://infostart.ru/public/174086/ можно все не читать, а почитать последний абзац, тот который 4.

В пустой(1 спр) базе, просто создать и записать элемент.
20 тыс. элементов 32 сек. х.з. быстро это или медленно.

+(89) файло

запустил мульйон ща скажу сколько времени.

+(91) 1 млн. эл. 25 мин. 14 сек.

Но по факту думаю что в больше половине времени это регистрация события в ЖР если его отключить полностью думаю прирост будет 50%. База весит 190 мб. ЖР весит 300 Мб.
Так что если нужно быстрее вырубай ЖР.