Спрашиваю совета у знающих людей:
есть запрос, который в цикле выполняется 100500 раз, соответственно им определяется производительность кода. Все что можно выжать из 1С, думаю, уже выжал. Стоит ли думать в сторону написания внешней компоненты для увеличения производительности? Может ли это существенно (кратно) изменить ситуацию?

Может это слабое место
"есть запрос, который в цикле выполняется 100500 раз"

(0) В цикле запросы это очень неправильно

(1)(2) расчет производственных графиков - по другому никак.

(3) Кидай кусок кода

(4) Там же адский алгоритм скорее всего

Круть! Онлайн отладка кода!

(0) Самописка или типовое решение?

(4) слушай, не хочется этим заморачиваться - уже давал на оптимизацию, смотрели и сам код и данные - думаю пройденный этап.
(7) самописная

(0) Смотря что Вы хотите от внешней компоненты и как Вы её будете делать

(3) избыточное хранение + расчет(подготовка данных) регламентами в несколько потоков?

получить данные в таблицы проиндексировать и брать данные из них в цикле

(8) План запроса гляньте на SQL!
Это если не менять алгоритм, структуру хранения и тд.

(0) и всё-таки рассмотрите вариант сделать один запрос и получить все необходимые данные один раз. И вместо запроса можно искать в индексированной таблице значений нужные строки, это будет намного быстрее.

(9) увеличения скорости работы кода
(10) думал об этом .. разбивать придется запрос, а он сам по себе не так долог - время теряется на том, что он повторяется очень много раз - реально порядка 500-700раз. Будет ли толк? время будет тратиться на стыковку данных потоков ...
(11) (12) да, это  понятно

Что там такого нужного делается 500 раз?

(14) может 1 раз данные получить и уже по тз индексирвоанной искать?

(3) компонентой вы запросы существенно не ускорите. Компонентой можно ускорить расчеты, убрав математику со скриптового языка в машинный код. А SQL все равно будет выполняться на сервере что так, что этак.

Сдается мне, алгоритм заложен неоптимальный.

(15) скорее всего разворачивание узлов

можно также посмотреть в сторону параллельного разворачивани яэтих самых узлов

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

(8), (21) Если оптимизация ничего не дает - тогда нужно переделывать структуру БД таким образом, чтобы не было множества запросов, и затем осуществить перенос данных из старых объектов в новые.

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

(21) А генерация текста запроса в зависимости от ситуации не поможет?

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

(23) см. (25)

Кстати можно перед выполнением попытаться прогреть кэш

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

(0) индексы в таблицах бд все сделаны, которые нужны?

(27) это что за тема - как делается?
(29) да

(28) "нужно отрабатывать одни  и те же данные, но в измененном виде на каждую итерацию (измененные предыдущим шагом) "

т.е. делаем запрос, обрабатываем данные, вносим данные в базу, делаем запрос и т.д.?

а если: делаем запрос, выгружаем в тз, обрабатываем данные, вносим данные в базу, вносим соответствующие изменения в ТЗ - и ничего не надо читать?

+(31) ничего не надо читать - это, в смысле, не надо делать ещё один запрос к измененным данным, т.к. они уже есть в ТЗ

(31) (32) запрос выдает результат, на основании которого меняются данные, не в базе, конечно,а в соответствующих ТЗ - эти ТЗ и есть исходники для запроса, там они обрабатываются и выдается новый рез-тат и тд. В итоге формируется целевая табличка, которая и пишется в базу при accept  пользователя

Позовите математика, может он вам другой алгоритм решения придумает.

(0) Не на Мавроди, случайно, работаете?

(33) т.е запрос не к базе, а к ТЗ идет в цикле?

(0) генетические алгоритмы - посмотри, можно ли их применить к твоей задаче.

(33) Зачем вообще в тз сохранять? Есть же временные таблицы.
Ну сгененрируйте сначала 1 запрос и выполните 1 раз.

(37) может тогда сразу нейронные сети?

(38) Неправильно выразился. Сделайте длинный состоящий из 500 запросов.
Кстати какие ограничения сейчас у пакетного запроса?

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

(41) к (30)

(40) не прокатит, следующий запрос должен использовать результат работы прошлых

забить раз так все сложно и выполнять ночью регламентным заданием

(43) А предыдущие запросы данные в БД меняют?

(44) Еще вариант выполнять в копии базы где никто не работает.

(43) Ты издеваешься что ли?
ВЫБРАТЬ
    ТЗ.Показатель
ПОМЕСТИТЬ втТЗ
ИЗ
    &ТЗ КАК ТЗ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втТЗ.Показатель
ПОМЕСТИТЬ втТЗ1
ИЗ
    втТЗ КАК втТЗ
;

////////////////////////////////////////////////////////////////////////////////
УНИЧТОЖИТЬ втТЗ
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втТЗ1.Показатель
ПОМЕСТИТЬ втТЗ
ИЗ
    втТЗ1 КАК втТЗ1
;

////////////////////////////////////////////////////////////////////////////////
УНИЧТОЖИТЬ втТЗ1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втТЗ.Показатель
ПОМЕСТИТЬ втТЗ1
ИЗ
    втТЗ КАК втТЗ

(47) Имеется ввиду: запрос - запись в БД - запрос - запись в БД и тд

(48) Нигде такого не написано. У него же написано, что результат предыдущего запроса выгружается в ТЗ и эта ТЗ используется в следующем. А пишется только результат последнего.

все эти пляски с запросом не помогут, тк алгоритм рекурсивный

(50) Дело не в алгоритме. В незнании ничего. Кроме запросов.

(50) Можно просто рассчитать примерное количество рекурсий. И например разбить на 5 запросов по 100.
И сделать 5 основных циклов плюс все остальные уже отдельно, по старому.

Обрабатывать ТЗ запросами - редкостный изврат.

(52) Ну попробуй сгрупрпируй запросы для алгоритма разузлования

(14) Когда все способы оптимизации использованы, и все равно медленно - надо использовать алгоритмическую оптимизацию.

(0) Вообще сложно размышлять о виртуальных запросах не видя чего же там именно нужно получать.
Но если он у тебя таки один и тот же базируется на результатах предыдущего, то внешняя компонента, или даже не компонента а просто прямой запрос к SQL тебе даст то чего нет в запросах 1С - Common Table Expressions. Если их понимаешь, то вполне возможно получишь очень ощутимый прирост.

(54) Если я правильно понял, то вот простейший пример разузлования.

ВЫБРАТЬ
    ПродукцияСпецификация.Ссылка КАК родитель,
    ВЫРАЗИТЬ(&Количество КАК ЧИСЛО) КАК колРодитель,
    ПродукцияСпецификация.Узел КАК Узел,
    (ВЫРАЗИТЬ(&Количество КАК ЧИСЛО)) * ПродукцияСпецификация.Количество КАК колУзел
ПОМЕСТИТЬ вт1
ИЗ
    Справочник.Продукция.Спецификация КАК ПродукцияСпецификация
ГДЕ
    ПродукцияСпецификация.Ссылка = &Ссылка
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт1.родитель
        ИНАЧЕ вт1.Узел
    КОНЕЦ КАК родитель,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт1.колРодитель
        ИНАЧЕ вт1.колУзел
    КОНЕЦ КАК колРодитель,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт1.Узел
        ИНАЧЕ ПродукцияСпецификация.Узел
    КОНЕЦ КАК Узел,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт1.колУзел
        ИНАЧЕ ПродукцияСпецификация.Количество * вт1.колУзел
    КОНЕЦ КАК колУзел
ПОМЕСТИТЬ вт2
ИЗ
    вт1 КАК вт1
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Продукция.Спецификация КАК ПродукцияСпецификация
        ПО вт1.Узел = ПродукцияСпецификация.Ссылка
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт2.родитель
        ИНАЧЕ вт2.Узел
    КОНЕЦ КАК родитель,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт2.колРодитель
        ИНАЧЕ вт2.колУзел
    КОНЕЦ КАК колРодитель,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт2.Узел
        ИНАЧЕ ПродукцияСпецификация.Узел
    КОНЕЦ КАК Узел,
    ВЫБОР
        КОГДА ПродукцияСпецификация.Ссылка ЕСТЬ NULL
            ТОГДА вт2.колУзел
        ИНАЧЕ ПродукцияСпецификация.Количество * вт2.колУзел
    КОНЕЦ КАК колУзел
ПОМЕСТИТЬ вт3
ИЗ
    вт2 КАК вт2
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Продукция.Спецификация КАК ПродукцияСпецификация
        ПО вт2.Узел = ПродукцияСпецификация.Ссылка

(57) И что разворачивает любую вложенность уровней?

(58) Здесь 3. Но я же сказал. Нужно сделать 1 запрос состоящий из 500. Но выполнить 1 раз.
После этого посмотреть если еще остались не разузлованные, тогда еще.

+ (59) Это будет быстрее, чем 500 запросов в цикле

(59) прочитай (28)

(61) И? Он делает то же самое, но просто из запроса выгружает в ТЗ, а потом обратно тз загоняет в запрос. Я предлагаю просто вместо ТЗ воспользоватся временной таблицей скуля.
Ну выход из итерации у него проверяется после каждого запроса. В моем случае это и не надо. Ну подумаешь пару десятков раз лишних крутанется. Но выигрыш будет.

(36) да
(37) что-то типа этого и происходит
(38) тоже пробовал - врем таблицы надо убивать после использования - выигрыша во времени не получилось
(48) (49) см. (33)
(56) спс, посмотрю

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

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

(64) Ну отбрасывать можно и запросом. Допустим те которые уже не разузловываются скидывать в отдельную временную таблицу.