Добрый день! Начну с предистории: был регистр накопления остаточный, но не закрывался никогда, был приход без расхода. Со временем он раздулся, решили изменить остаточный на оборотный. Поменяли (на самом деле в новый регистр перетащили все записи старого с регистратором Корректировка записей регистров, почистили и удалили старый регистр, внесли соответствующие изменения в модулях, вроде все сдалали как надо, все работает, но не так как хотелось бы). Данные, для записи в этот регитср, собираются сначала в большую таблицу значений (более 100 тыс. строк), затем из этой таблицы порциями инфа записывается в регистр (по 20 000 записей за раз) с помощью метода Записать(Ложь). Теперь о самой проблеме: после того как изменился вид регистра, эта запись стала проходить намного дольше (уж очень на много), в чем может быть дело?
И еще вопрос, нигде не нашла инфы: есть ли какое-то ограничение на количество записей в наборе при использовании метода Записать(), прежние программеры ограничили количество записей в наборе - для регистра бухии до 10 000, а для регистра накопления 20 000.

без ограничения на количество записей в одной итерации - не работает? сколько записей всего?

и всё на один регистратор?
лучше разбейте по разными документам, а не Записать(Ложь); используйте

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

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

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

что за состав измерений у регистра?

(5) Можно поподробнее про отключение и включение итогов: каким образом?

(7) РегистрНакопленияМенеджер.<Имя регистра накопления> (AccumulationRegisterManager.<Имя регистра накопления>)
УстановитьИспользованиеИтогов (SetTotalsUsing)
Синтаксис:

УстановитьИспользованиеИтогов(<Признак>)
Параметры:

<Признак> (обязательный)

Тип: Булево.
Признак использования итогов.

кривая реализация, если нельзя разбить записи регистра на разные наборы со своим регистратором. Таким "разделителем" наборов может выступить Измерение регистра, контролировать введён док или нет - по нему

(8) спасибо, идея хорошая, но пугает, то, что "При установке признака использования итогов производится пересчет всех итогов." Не будет ли этот пересчет по времени дольше, чем сейчас. Надо будет попробовать.

(6) состав разнообразен: счета, виды субконто, сами субконто, первичные документы и т.д. Настораживает дажк кол-во измерений - 22.

(11) в документ реквизит Счет, бейте по нему наборы.
Регистр конечо ахтунг, берите пример с РАУЗ, 4 измерения - но охватывают практически всё, сама идея хороша

(10) иначе у вас происходит пересчет итогов при каждой записи набора. Не в одной явной транзакции же делаете?

короче я за переделать под принцип РАУЗ, самое то для вашего случая

(11) Многовато (вряд ли нужна такая аналитика).

(14) ок, спасибо, попробую поиграться с итогами и подумать над РАУЗом

(15)+ Проверьте индексируемость измерений: если индексируемых много, индекс будет большим.

(15) много отчетов строятся на данных этого регистра, поэтому уменьшить никак

(17) как не странно у всех измерений стоит
Индексировать: Не индексировать
Использование итогов: Истина
Корректно ли это?

во всех типовых так почти, мало что индексируется принудительно (в РН). Тут тормоза в основном из-за кучи аналитик и больших объёмов, в таких случаях проектируют систему по другому (тот же РАУЗ, РН УчетЗатрат), а не пытаются писать в регисты мильёны записей в разрезе десятков аналитик