Оператор if против указателя на функцию

1. Один косвенный вызов функции дороже, чем одно условие if.

2. Несколько условий if обходятся дороже, чем косвенный вызов функции.

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

Итак, мой совет: перестаньте беспокоиться о стоимости if или вызова функции, пока вы программируете пользовательский интерфейс. Думайте о таких вещах только внутри ваших трудоемких алгоритмов.

Однако, если вы обнаружите, что действительно используете сложные операторы if/else и/или switch внутри своего внутреннего цикла, вы можете оптимизировать их, заменив их косвенными вызовами функций.

Изменить:
Вы говорите, что у вас 600 проверок в секунду. Предполагая, что вам нужно обработать только один случай if (ситуация, когда if работает быстрее), вы «экономите» примерно 6 микросекунд в секунду, не используя косвенный указатель на функцию, что составляет 0,0006% времени выполнения. Усилий точно не стоит...

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

extern void fun0 ( unsigned int );
extern void fun1 ( unsigned int );

void (*fun(unsigned int));


void dofun0 ( unsigned int x, unsigned int y )
{
    if(x) fun0(y);
    else  fun1(y);
}

void dofun ( unsigned int y )
{
    fun(y);
}

дает что-то вроде этого, например

Disassembly of section .text:

00000000 <dofun0>:
   0:   e3500000    cmp r0, #0
   4:   e92d4008    push    {r3, lr}
   8:   e1a00001    mov r0, r1
   c:   1a000002    bne 1c <dofun0+0x1c>
  10:   ebfffffe    bl  0 <fun1>
  14:   e8bd4008    pop {r3, lr}
  18:   e12fff1e    bx  lr
  1c:   ebfffffe    bl  0 <fun0>
  20:   e8bd4008    pop {r3, lr}
  24:   e12fff1e    bx  lr

00000028 <dofun>:
  28:   e92d4008    push    {r3, lr}
  2c:   ebfffffe    bl  0 <fun>
  30:   e8bd4008    pop {r3, lr}
  34:   e12fff1e    bx  lr

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

Имхо, указатели немного чище для вызова подпрограмм с большим количеством аргументов:

int good(int a, int b, int c, char *d) { ... }
int bad (int a, int b, int c, char *d) { ... }
int ugly(int a, int b, int c, char *d) { ... }

Прямые звонки:

if (is_good) {
   good(1,2,3,"fire!");
} else if (is_bad) {
   bad(1,2,3,"fire!");
} else {
   ugly(1,2,3,"fire!");
}

Косвенные звонки:

if (is_good) {
   f = good;
} else if (is_bad) {
   f = bad;
} else {
   f = ugly;
}

...

f(1,2,3,"fire!");

Чтобы получить точные результаты, потребуются измерения времени, но:
я уверен, что if имеет меньше накладных расходов, чем полный вызов функции.
->If быстрее

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

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

Если вы собираетесь проверять эти вещи только в одном центральном месте, я рекомендую использовать switch, если возможно, и if/else, если нет.

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

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

Однажды я обнаружил случай, когда GCC 5.3 удалось сжать сложный набор switch cases, включающий несколько вызовов функций в каждом случае, в единую справочную таблицу без ответвлений, какие данные загружать в регистры. Я ожидал увидеть таблицу переходов, но она пропустила всю таблицу переходов и просто выяснила, какие данные нужно загрузить для каждого случая без ветвления вообще.

Я был настолько впечатлен, что даже не осознавал, что через все эти cases вызывающие функции все может сводиться к загрузке данных из LUT. Но я почти уверен, что он не смог бы раздавить мой код, если бы были задействованы косвенные вызовы функций. В конечном итоге они служат барьерами оптимизации, если только оптимизатор не настолько умен, что может генерировать все пути кода для каждого возможного типа указателя функции, который может быть вызван, выясняя, какие функции будут вызываться через данный FP.