Доброго времени суток. С недавних пор встал вопрос по оптимизации сохранения и восстановления регламентированного отчета «алкогольная декларация» форма № 8.

В модуле формы данного отчета есть функция «Сохранить». В ней реализовано сохранение через тип данных ХранилищеЗначения.
Если использовать данный тип, то выгрузка за 1 квартал, содержащая 13500 записей сохраняется учитывая заполение около 1,5 часов.

Я попробовал заменить Хранилище значения на ТЧ документа(поскольку нужно, чтобы сформированный отчет хранился в базе.)
В итоге, к сожалению процесс сохранения увеличился раза в 1,5((.

Далее была идея сохранять записи также в ТЧ документа при формировании отчета напрямую, НО, следуя здравой логике, что выполнить формирование и дальнейшее сохранение, а что эти действия одновременно – то по идее времени потратиться же столько. Тем более использоание ТЧ показало замедление.
Еще один интересный момент - при замере производительности - около 42% времени тратиться на процедуру "ОбновитьСтруктуруМногострочногоРаздела" в общем модуле РегламентированныйОтчетАлкоПриложение8. Там код
```1c
    ЗначениеЯчейки = ОбластьЯчейки.Значение;
```
 занимает около 45 % времени. Тоесть по идее затартен сам механизм чтения из макета. Напрашивается вопрос - зачем нужно ОбновитьСтруктуруМногострочногоРаздела при восстановлении отчета?

Нужны любые предложения по убыстрению сохранения отчета.
---
Manticor,
Доброго времени суток.
Читал сегодня вот эту статью Универсальный отчет (4.2.0.1)
Так вот пункт "Про скорость" из этой статьи натолкнул на мысль, ее изложу ниже
1) разбить таблицу отчета (ведь вы используете ТЧ) на секции по 100 строк
2) сохранять каждую такую секцию отдельно в ХранилищеЗначений, собирая адреса Хранилищ
3) сохранить массив адресов ХранлищЗначений для данного отчета где угодно, он не будет играть особой роли
для быстродействия
4) при восстановлении обратным путем склеивать отчет

Думаю, должно немного ускорить процесс)
---
Manticor,
Доброго времени суток.
Читал сегодня вот эту статью Универсальный отчет (4.2.0.1)
Так вот пункт "Про скорость" из этой статьи натолкнул на мысль, ее изложу ниже
1) разбить таблицу отчета (ведь вы используете ТЧ) на секции по 100 строк
2) сохранять каждую такую секцию отдельно в ХранилищеЗначений, собирая адреса Хранилищ
3) сохранить массив адресов ХранлищЗначений для данного отчета где угодно, он не будет играть особой роли
для быстродействия
4) при восстановлении обратным путем склеивать отчет

Думаю, должно немного ускорить процесс)
---
Как вариант, можно попробовать создать регистр сведений с измерением "Название" - тип "Строка" и ресурсом "Значение" - тип "ХранилищеЗначений". При сохранении - делать запись в регистр. В качестве значения сохранять табличную часть

[1C-CODE]
        Имя = "Отчет алкогольная декларация " + Номер;
        Значение = ТЧ.Выгрузить();
 Набор=РегистрыСведений.ХранилищеДанных.СоздатьНаборЗаписей();
 Набор.Отбор.Имя.Установить(Имя,Истина);
 Запись=Набор.Добавить();
 Запись.Имя=Имя;
 ХранилищеЗначения=Новый ХранилищеЗначения(Значение);
 Запись.Значение=ХранилищеЗначения;
<\code>
---
Romeo_1c_programmer, ВЫ предлагаете не уходить от ХранилищаЗначений? Тоесть из регитсра данные будуь читаться быстрее, нежели чем из ТЧ? Все равно по отладчику время большее время тратиться в процедуре ОбновитьСтруктуруМногострочногоРаздела
---
Если нужно сохранять печатную форму, я бы сохранял в excel (во внешнем файле), а при необходимости написал бы обработку которая этот файл читает и обрабатывал бы данные дальше.
Или другой вариант, который я собираюсь реализовывать в своей базе - хранить саму декларацию в виде документа (нужна табличная часть - вывел на экран, нужно отправит в ФСРАР - сформировал xml).
---
Gerts, я как раз решил сделать через ТЧ документа. В итоге получается, что соханение идет в 1,5- 2 раза медленнее. Я так думаю, что при сохраении выгрузки данные читаются из макета. Момжет стоит попытаться сделать сохранения не из макета - ячеек а структуры, ранее сформированной.
А так отладчик показывает 52% времени на

```1c
    Функция СобратьДанныеТекущегоТаблПоля(ТабличноеПоле) Экспорт
    ТабличноеПолеИмя = ТабличноеПоле.Имя;

    СтруктураДанныхПоля = Новый Структура;

    Для Инд = 0 По ТабличноеПоле.Области.Количество() - 1 Цикл
    ТекущаяОбласть = ТабличноеПоле.Области[Инд];

    Если Не ТекущаяОбласть.ТипОбласти = ТипОбластиЯчеекТабличногоДокумента.Прямоугольник Тогда
    Продолжить;
    КонецЕсли;

    Если ТекущаяОбласть.СодержитЗначение <> Истина Тогда
    Продолжить;
    КонецЕсли;

    ИмяПоказателя = ТекущаяОбласть.Имя;
    ЗначениеПоказателя = ТекущаяОбласть.Значение; //52 % времени

    СтруктураДанныхПоля.Вставить(ИмяПоказателя, ЗначениеПоказателя);
    КонецЦикла;

    Возврат СтруктураДанныхПоля;

    КонецФункции // СобратьДанныеТекущегоТаблПоля()
```

Процедуру ОбновитьСтруктуруМногострочногоРаздела - я вообще закоментил, без нее вроде работает)
---
Вы меня пугаете. Я скорее всего на следующей неделе начну документы воздавать (сейчас у меня в виде отчетов это дело работает). Не хотелось бы, чтоб пользователи ощутили тормоза в программе.
---
Gerts, могу скинуть отчет - зацените запись в ТЧ
---
Добрый день.
(7)Manticor, скиньте - гляну. адрес gerts_n(щенок)mail.ru
---
Gerts, оказывается медленно работало потому, что тесты делал на своей раб. машине, а не на сервере как ранее. Рефакторинг с ТЧ - дал резуьтат.
По крайней мере сохранение 1 месяца идет за 8 минут, тогда как до рефакторинга шло около 22 минут. Не стал заморачиваться с абсолютно всеми структурами - в ТЧ загнал только данные сугубо нужные для отчетности. Остальное так и оставил в хранилище.

Правда ранее пробовал все структуры данных помещать/читать из ТЧ. Сохранение/загрузка при этом также в разы убыстряются, но при проверке выгрузки не выводит ошибок. Просто дальше не охота код копать в глубину - по видимому смещается где то индекс.

(8) sergnik, тоесть Вы предлагаете посегментно записывать/считывать данные? Наверное стоит попробовать. По идее таким способом мы уменьшаем количество элементов в хранилише(тоесть нет такого количества, какое было ранее), НО, как показала практика именно из за хранилища значений а также повторного обращения к данным выгрузки не через сформированные ранее структуры а через данные в макете - ведет к замедленю((