Много мелких функций или одна большая? Опции

[GYUR22]

Есть одна большая функция в программе - которую можно поделить на много мелких ...
Вопрос как выгоднее по скорости исполнения - разделить ее на 18 мелких (по смыслу) или оставить как есть?

[GYUR22]

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

имхо:
Результат в моем случае проверить сложно т.к. размер кода - будет один и тотже -функции используются по разу
а скорость отклика - уарта мне точно померять пока не представляется возможным - точность +/- 1 ms уже не устроит

а вот результат по разбиению исполнения массива данных - был виден и дал выигрыш как раз ~1ms - спасибо за наводку

Всем спасибо дальше как говориться куда кривая выведет

[defunct]

имхо:
Результат в моем случае проверить сложно т.к. размер кода - будет один и тотже -функции используются по разу
а скорость отклика - уарта мне точно померять пока не представляется возможным - точность +/- 1 ms уже не устроит

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

Если разить вашу теорию, то и данные предназначенные для помещения в секции EEPROM (это при помощи атрибутов в gcc происходит) ИНОГДА могут оказаться в другой секции.
Это абсурд!

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

[demiurg_spb]

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

Идеологически согласен.
Кстати, Вы видели в моём примере много прагм и атрибутов?
Человек спросил как это сделать - я дал однозначный рецепт.
Потом сюда приплели даже микрософтовский компилятор и кеш инструкций, хотя тема находится в подфоруме микроконтроллеры/AVR
и вопрос касался avr-gcc...

и - кстати таки да данные могут оказаться совсем не в той секции где ожидаешь, при переносе такого проекта на другой проц.

Какие Ваши предложения на сей счёт? Отказаться от использования PROGMEM, EEMEM, ISR и вообще не включать компьютер?
Атрибуты в gcc - это почти что основополагающий механизм в случае кросс-компиляции для avr.
Если Вы внимательно читали мои посты, то могли бы подметить, что я рекомендовал оставить лишь квалификатор static, ибо это и необходимо и достаточно для локальных функций.