Вложенные таблицы значений - оптимизация #273951

Создаю вложенные таблицы значений. В каждой строке - вложенная таблица определенной структуры. Вот так вот - работает    КонецЦикла; (ТЗСтруктура - обычная таблица значений) но - смущает большое количество вызовов - цифрочка в замере производительности достаточно весомая - ТЗ.Структура = СоздатьОбъект("ТаблицаЗначений"); и 1С устойчиво вылетает по некорректной операции, хотя в описании метода заполнить говорится, что первый параметр для Заполнить может быть таблицей значений. Ломаю голову - как это оптимизировать.

2 Это место очень плохо поддается оптимизации, т.к. создавать объект на каждую строку в любом случае придется.

разве нельзя выгрузить в переменную любого типа?

Просто обнадежило "<Знач> - значение одиночное или список значений или таблица значений" в СП в описании метода Заполнить Возможно, если по каждой строке создать объекты, а потом Заполнить - это будет быстрее, чем по каждой строке "Выгрузить"

Ну и ? Всё правильно там написано, ты заполняешь колонку "Структура" значениями из другой ТЗ, если в ней была бы Колонка "Структура", то всё корректно бы заполнилось....Но это никакого отношения не имеет к вложенным ТЗ.

вот так вот тоже не работает  - хотя вроде и можно "в переменную любого типа" - "если пустое - то создается..." так что похоже что без построчного создания таблиц ничего не получится.

Есть выход, Наталья! Посмотри индексированную таблицу

Без создать объект не выйдет ...

про индексированные знаю. Пока не пользуюсь. 1С++ - "в планах" - пока просто бардак разгрести. Вложенные тоже классно работают - просто при большом количестве строк - в отладчике цифрочка в 4% времени на это самое создание таблиц смутила.

Фигня, просто вызывается часто :)

ну да, я догадалась )) В цикле по строкам таблицы - около 1.5 тыс строк - вот и задалась оптимизацией ))

Вынеси создание объекта "ТаблицаЗначений" за пределы цикла.

можно оптимизировать так

Можно и проще и быстрее: Сначала структуру загоним в строку: ТЗСтруктураВнутр = ЗначениеВСтрокуВнутр(ТЗСтруктура); а потом, в цикле по строкам достаточно сделать: ТЗ.Структура = ЗначениеИзСтрокиВнутр(ТЗСтруктураВнутр);

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

не могли бы Вы вкратце описать цель создания таких вложенных таблиц? я почему спрашиваю:  может быть, можно без вложенных сделать? сам пока не встречался с ситуацией, когда нельзя было бы вместо вложенных таблиц использовать обычную ТЗ. Был бы рад расширить свой кругозор :)

Действительно, но не сравнить с

Читал. Много плакал. Неужели сложно было послушать инженера-технолога по обработке металлов резаньем ;)...

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

с обычными таблицами все то же самое реализуемо, но не слишком красиво и не универсально.

Присоединяюсь к Барбариске. использование вложенных ТЗ - на порядок упрощает программинг и читабельность кода. МАСТ ХЭВ! А про строку - спасибо. вообщем-то про это знаю, но не использовал (не думал) потому как для отчетов/обработок где используются в массовом кол-ве вложенные ТЗ - время выполнения как правило не критично.. потому как не каждые 5 минут это делается..

А Баба Яга против! :) Использование вложенных ТЗ конечно чертовски удобно и упрощает, но при большом количестве строк создает жуткие тормоза. Упреждаю ответы что лечится формексом - знаю, но не везде уместно...

бабу-Ягу в ступу! и на луну! ;-) надо трезво подходить к оценке обрабатываемых объемов информации иприменять соответсвующие методы... то что применимо на 100 наборов данных - будет работать нормально, но на 100000 - тормозить ужасно и имеет смысл задуматься об оптимизации/смене подхода.. так и ТЗ... вложенные ТЗ _обычно_ - отражение какой-то иерархии.. можно тупо в ТЗ загнать всю иерархию от A до Z, а можно - кусочками.. сначала А-АА-ААА-АААА, освободили, обрабатываем B... итого объем лимитирован "одной неделимой единицей для обработки"... по всякому ведь можно...

вообще-то я спрашивал про конкретное применение. Ну то есть о чём отчёт, что надо вывести, и т.д. Золотой мой, ты в курсе, что результат бух.запроса (с несколькими вызовами метода ИспользоватьСубконто, и с заданной периодичностью, и по субсчетам, и т.д.) хранится именно в виде ОДНОЙ ТЗ, без всякой вложенности. И ничего, фунтициклирует! И не так уж тормозит при обходе. Спрашивается, мы-то чем хуже?

Вообще то любой алгоритм с вложенными ТЗ реализуется ТЗ обычной и при этом не надо заниматься оптимизацией, а просто грамотно спроектировать обычную ТЗ... И работать будет быстрее

объединение запросов, которые невозможно объединить на языке запросов - чем не конкретная задача? Сложный отчет с кучей группировок, которые можно включать-отключать-переставлять-выводить итоги сверху/снизу... - замучишься простой таблицей реализовать. Вложенными - получается сделать это в практически универсальном виде. может и быстрее...

+1

Кстати, алгоритм, который вчера переписывала - было написано без вложенных ТЗ, нечитаемых около 800 строк текста без комментариев - работал не всегда корректно, потому и взялась за переписывание. Медленнее работать не стало. Короче стало по тексту почти вдвое.

Со вложенными таблицами удобно рекурсивно работать а еще можно писать на "0" и "1" и считать на счетах. По твоему _ЛЮБЫЕ_ данные можно представить виде одной таблицы? Удакчи засунуть в одну ТЗ дерево спецификаций, например, да и вообще любое дерево.

Совершенно справедливо, использование объектов более высокого уровня абстракции обычно сопровождается снижением кода в два раза :)) З.Ы. Зато такой код намного труднее для понимания

пишу комментарии практически через строчку + переменные стараюсь именовать правильно. К тому же не факт, что даже без комментариев было бы труднее для понимания...

А если сделать всего две таблицы: Таблицу-Владелец и подчиненную таблицу... При этом в таблице-владельце добавить дополнительную колонку(или две) - "Диапазон", где будут указываться диапазон номеров строк подчиненной ТЗ, соответствующих строке ТЗ-владельца. Программинг при этом усложнится, но засчет этого будет выигрышь по времени... Не надо будет создавать тысячу структур, а будет одна большая подчиненная таблица...

Все дело в том, что тебе уже многие вещи стали очевидными и понятными. А ты посади кого-нить со стороны - без многа пЫва не разберет )))

а если уровня подчинения не два, а больше? а если их число заранее не известно?

с пЫвом или без пЫва - при чем здесь вложенности. Иногда и без вложенностей такие шедевры бывают, что даже пЫво не помогает ))