Кто-то может проверял уже...
Насколько велики накладные расходы на вызов этого метода?
Подмывает окончательно универсализировать один блок, заменив развесистое дерево "Если" с обработкой особых условий на Выполнить().
Но количество итераций немаленькое, поэтому волнует насколько сильно упадет производительность...

выкладывай свой г-код не будь жаден, хоть посмотрю до чего докатились ваятели нетленок

Не вижу смысла ТС-у оффтопить.

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

Я логичен?

(3) нет, не прав.  У меня допустим чудесно справочник Алгоритмы интегрирован с различными проверками определенных документов, при проведении, записи и т.д.

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

Не проверял, не создавалось ситуации, когда я был вынужден к использованию метода в узком месте.
Теоретически - накладные расходы - это компиляция при каждом выполнении, а не один раз при создании объекта.
Если выполняться будет один раз, можно, вероятно, считать расходы низкими (т.е. близкими к обычному выполнению).
Кроме, конечно, других минусов - невозможности отладки, отсутвии синтаксического контроля при сохранении и тп.

(6) Спасибо, кэп.

Ок.Если нужна субъектиная оценка - существенно медленнее.

Для устранения развесистых Если умными людьми было придумано ООП с виртуальными функциями.
А одинэсников считают рылом не вышедши, и ООП не дают.
Ну хрен с ним, с ООП, хотя бы делегаты на функции бы дали, так и такой малости нет.

(0) Подумай об отладке

есть данные которые кешируются или методы с повторным изпользованием

думаю Выполнить() ложит болт на эти весьма важные факты, а если это в итерациях - то это не болт уже, а бревно

(7)
Производительность упадет.
А насколько - зависит от кода, перетаскиваемого в Выполнить.

(8) Жаль... Надеялся, что может все-таки кэширует уже копилированные куски при многократных итерациях.
(9) В данном конкретном случае плодить кучу наследников-близнецов ради смехотворной задачи как-то не алё было бы...
(10) Подумал. Там небольшие кусочки, не страшно.
(11) Вот и я так думаю...

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

(12) В моем случае, думаю, зависит как раз не от кода (его немножко и он простой), а от базовых накладных расходов.

если кончено математику считать то наверно сильно отличается, если в базу писать/читать то не заметно

(14) Да какая в "опу" разница? Что не засунь - выполняться будет одинаково. Добавляются затраты на компиляцию и т.п.

(17) Имеется в виду полный контекст задачи, а не конкретный оператор.

Иначе это обсуждение известного коня в вакууме

Для i=1 по 100000 цикл б=123.1; ц=321.6; а=б*ц; КонецЦикла; // 3.29 с

Для i=1 по 100000 цикл Выполнить("б=123.1; ц=321.6; а=б*ц;"); КонецЦикла; // 0.09 с

Это будет ответом на накладные расходы?

Время наборот, перепутал когда писал

(20) Да. Будет. Спасибо. Уже сам понял, что проще было самому простейший тест забабахать, чем от теоретегов отбиваться.
а = 1; на миллионе итераций за 3 сек выполнилось.
Тоже самое через Выполнить() пихтарит до сих пор.
Ну его в задницу, всем спасибо.

О! Закончило. На миллионе итераций разница в производительности присвоения единичке составила два порядка.

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

Сотни тыщ в ЧАС? Большое? Гы :)

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

А если такого рода алгоритмы навешивать на реальные объекты БД с которыми каждый день работают хомячки, то самое правильное расчлетить автора и отдать на съедение тем самым хомячкам

С другой стороны, абсолютно по барабану (с т.з производительности) писать Док.Записать(Режим.Проведение) или Выполнить("Док.Записать(Режим.Проведение)"). Думаю, тема исчерпана ( с моей стороны по кр мере)

(25) ну там как бэ не только это есть
(26) все оправдано и допустимо, не беспокойтесь

(26) Да ну. Если десяток раз за проведение используется - то монопенисуально с точки зрения производительности.
(27) Тоже считаю тему исчерпанной.

(25) может стоит обратить внимание на количество обращений? если 100k это "гы", то есть смысл подумать над кешированием и изменении алгоритма