В каких случаях эффективнее дублирование кода вместо вызова функции?

Question

[Виталий]

Сейчас речь идёт не о скорости разработки и не о рисках сделать ошибку. Под эффективностью подразумеваю оптимальное соотношение скорости выполнения и размера исполняемого файла. К примеру, вместо вызова get/set методов в простых случаях эффективнее делать обращение к свойству - насколько мне известно, такую подстановку делают грамотные оптимизаторы. Можете ли вы с теоретической точки зрения обобщить правило ситуации, при которой эффективнее подставлять тело функции вместо её вызова?

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

Answer 1

[xmoonlight]

Если на данный момент функция в памяти не была определена (не была востребована) и использование логики работы кода этой функции планируется строго один раз, то разумнее использовать сразу само тело функции.

Comments

[Виталий]

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

[Saboteur]

Виталий, С точки зрения ассемблера, всегда проще выполнять код подряд, чем вызывать функцию (тратя время на call/return и помещение в стек). Но при этом у вас одна и таже функция дважды в памяти (тратится время на загрузку программы в память, тратиться само место в памяти). И если нужно что-то подправить, нужно править несколько раз подряд.

Неопределенные ситуации нужно смотреть по конкретным вашим хотелкам - в каком месте вам безразлично пару лишних тактов, а в каком несколько лишних байт в RAM.

[xmoonlight]

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

В целом, больше 3х операций в теле функции и вызов такой функции более одного раза - лучше будет использовать функцию.

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

[Виталий]

xmoonlight, спасибо.

Answer 2

[res2001]

Всегда пишите функции.
Выставьте ключи оптимизации в компиляторе и отдайте этот вопрос на откуп компилятору - они справляются с этим на ура.
Вручную стоит "инлайнить" только какие-то однострочные функции, указав inline в описании функции. Но обычно компиляторы именно к этим функциям применяют подобную оптимизацию.

Comments

[Виталий]

Дело в том, что я не спрашивал совета о том, как мне стоит делать и как не стоит. Вопрос, как мне кажется, формулировался достаточно понятно: мы не учитываем сложность поддержки, речь ведётся исключительно о скорости выполнения и размере исполняемого файла с исследовательской точки зрения.

[MiiNiPaa]

Указание inline при определении функции не гарантирет, что встраивание произойдёт. Если компилятор решит, что встраивание невыгодно в данном случае, то он проигнорирует inline. Фактически это всего-лишь даёт два шанса на встраивание функции: компилятором и линковщиком.

[Виталий]

MiiNiPaa, кажется, мы подбираемся к сути вопроса. Попробую тогда переформулировать его так: в каких случаях компилятор может решить более выгодным использовать inline вместо call, а при каких условиях сочтёт нужным проигнорировать?

[res2001]

Виталий, Откомпилируйте вашу программу в VS с добавлением ключа -Wall и посмотрите какие функции компилятор "инлайнит" сам, с какими inline соглашается с вами, а с какими не соглашается.
Для gcc аналогичной опции не знаю.
На вашу последнюю формулировку ответ могут дать только разработчики конкретного компилятора.
Если же взять формулировку из темы, то ответ прост: в плане быстродействия всегда inline эффективнее вызовов, в плане размера программы - всегда функции предпочтительнее встраивания.
Учитывая, что практически не возможно написать мало мальски сложную программу без использования функций, то на ваш вопрос нет однозначного ответа. Так как требования размера и быстродействия противоречивы, то всегда нужно искать компромисс.
Обычно, вы, как программист, знаете какой участок кода у вас критичный по скорости, именно в нем и следует применять inline и другие оптимизации. На остальной код обычно не стоит тратить много времени для оптимизаций, главное чтоб работал без ошибок и был легко сопровождаемым.

[MiiNiPaa]

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

[res2001]

MiiNiPaa, В лучшем случае вызов будет таким же быстрым как и встраивание, т.к. встроенная функция так же будет в кэше, имхо.

[Ariox41]

Виталий, в gcc есть атрибут __attribute__((always_inline)), который гарантирует встраивание. Но его не рекомендуют использовать, т.к. на практике это только усложняет разработку, но не приводит к заметному повышению производительности - у компилятора лучше получается определять, когда необходимо встраивание. В VC вроде бы тоже есть подобный атрибут.

[MiiNiPaa]

Ariox41, __forceinline

Answer 3

[SolidMinus]

Если вставлять inline функции, то бинарный код в размере очень сильно будет расти, но будет скорость выполнения будет также расти.

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

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

Если размер кода так критичен, но и нужна скорость, то можно выставить _fastcall перед определением функции, тогда вместо _cdecl функция будет вызываться без передачи параметров через стек, а передаваться внутри регистров. Это увеличит скорость вызова функций. Но не стоит злоупотреблять, т.к регистры используются для "быстрых вычислений", без доступа к памяти, и огромное количество _fastcall функций заставит компилятор перед вызовом функций постоянно сохранять состояние регистров, а потом восстанавливать.

Решается это все настройками оптимизатора на скорость или размер кода. При выставленной оптимизации по размеру кода спецификатор _inline игнорируется.

Comments

[Виталий]

К сожалению, это не ответ на поставленный вопрос, но информация о _fastcall и _cdecl была полезной - спасибо.

[SolidMinus]

Виталий, Почему?

Можете ли вы с теоретической точки зрения обобщить правило ситуации, при которой эффективнее подставлять тело функции вместо её вызова?

Я же ответил на этот вопрос:

Поскольку если делать вызовы функции, то, например, в цикле это может в реал-тайм системах дать очень сильный эффект

Важна скорость - подставляй, нужен размер маленький - вызывай. Просто же.

[Виталий]

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

[SolidMinus]

Виталий,

Если на данный момент функция в памяти не была определена (не была востребована) и использование логики работы кода этой функции планируется строго один раз, то разумнее использовать сразу само тело функции.

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

Всегда пишите функции.
Выставьте ключи оптимизации в компиляторе и отдайте этот вопрос на откуп компилятору - они справляются с этим на ура.
Вручную стоит "инлайнить" только какие-то однострочные функции, указав inline в описании функции. Но обычно компиляторы именно к этим функциям применяют подобную оптимизацию.

А этот ответ не учитывает тот факт, что однострочные функции даже без указания inline спецификатора будут инлайнится оптимизатором, так что совет не действителен и выполняется автоматически. Из всех этих советов дельный ответ дал только Fortop, остальные дали очевидные вещи. Я же дал вам инфу про то что оптимизатор сам никогда не решит: конвенция вызовов функций: _stdcall, _cdecl, _fastcall.

У меня сложилось стойкое ощущение, что вы решили сами взять на себя функцию оптимизатора, что заранее обречено на провал. Иначе я не понимаю почему ответы которые являются копипастой работы оптимизатора выделены в ответ?

[Виталий]

SolidMinus, потому, что я спрашивал именно про работу оптимизатора.
Впрочем, мне не жалко, нет причин выяснять отношения)

[SolidMinus]

Виталий, хм, странно

Можете ли вы с теоретической точки зрения обобщить правило ситуации, при которой эффективнее подставлять тело функции вместо её вызова?

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

Answer 4

[Fortop]

Всего два момента.

• Размер кода
  
• Критически важные ограничения по скорости выполнения (а не разработки)
  

Первое напрямую влияет на цену поддержки такого решения.
Второе поднимает или убирает лимиты на цену его поддержки.

Написание отдельных оптимизаторов идет в той же канве, если задача частовстречающаяся, а без нее никак, то становится выгодным написать оптимизацию.

Соотношение скорости выполнения и размера вторично - увы.

Раз пациент упорствует, то

@vitali1995, в вакууме разработчики не работают.

Вам нужен рерсурс по исследованиям. Вот там придумают и обоснуют.

Впрочем... Математику учили?

Вам нужно найти минимум от функции по time, или по size
f(sum(size), time)
Где sum(size) это сумма размеров всех функций в коде в комбинации подстановок
А time это время работы этого кода

Comments

[Виталий]

Вы внимательно читаете вопросы? Я ведь оговорил, что мы не учитываем сложность поддержки - речь ведётся исключительно об этих двух показателях "в вакууме".

[Fortop]

Виталий, в вакууме разработчики не работают.

Вам нужен рерсурс по исследованиям. Вот там придумают и обоснуют.

Впрочем... Математику учили?

Вам нужно найти минимум от функции по time, или по size
f(sum(size), time)
Где sum(size) это сумма размеров всех функций в коде в комбинации подстановок
А time это время работы этого кода

[Виталий]

Fortop, спасибо, уже что-то похожее на решение)

[Fortop]

Виталий, и на практике он для большинства случаев не рабочий.

Для этого вам нужно собирать runtime профили выполнения приложения и только после этого вы сможете компилировать его.
Хуже того - профили будут меняться от входных данных.

Что-то сделали в JIT в той же JVM можете почитать об их оптимизациях.