Значи имам един голям фрагмент от от примерния вид:
if(val == aa) { .... }
else if(val == bb) { ... }
else if(val == cc) { ... }
else if(val == dd) { ... }
.....
.....
else { ... }

Сравненията са с непоследователни стойности. Опитвам се да измисля начин за оптимизация на тоя пасаж за по-бързо изпълнение. Вече съм вкарал предварителни проверки дали изобщо да идвам на него, и съм подредил иф-вете според вероятността да се случат.

Някакви нестандартни идеи как още да го забързам?

PS. switch() върши точно същото, така че не е оптимизация

Ако компилаторът е умен, switch case е най-бързото, ифове няма, само табличен jump. Ако кейсовете са малко разхвърляни, това ще работи добре, въпреки, чи ще има много елементи, които сочат към default. Aко има огромни разлики, компилаторът генерира сортирана таблица и се ползва бинарно търсене. Дали ще е по-ефективно, зависи от броя на елементите. И в двата случая губиш от това, че не ползваш, че ти е известна вероятността за влизане в определен кейс. Опитай се да се сшретнеш някакъв реалистичен тест и виж кое е по-добро.

Вече го пробвах със switch() под GCC в прозорците, и под XC32 (с -О3 оптимизация).
Разликата в изпълнението е 0.059%

Таблица или мащабиране + таблица? Тогава няма да имаш никакви проверки

От чисто любопитство - две или повече различни условия 'aa' 'bb' в условната част могат ли да извикат един и същ код в частта с къдравите скоби ?

if(aa) then {ala bala}
if(bb) then {portokala}
if(cc) then {ala bala}

...или всяко условие извиква уникален код.

if(aa) then {ala}
if(bb) then {bala}
if(cc) then {portokala}

Всяко е уникално

switch/case e по-бърз за изпълнение от if стейтмънта, разбъркай порядъка на if цикъла като започнеш от условието с най малка вероятност и завършиш с условието с най-голяма и провери отново производителността. Няма универсална рецепта за оптимизация, всичко е според кода, и понеже нямам код, няма как да ти дам съвет.

той така или иначе GCC ще оптимизира switch/case/if/else

Сега младоците ги учат, че в таква ситуация се взема по-мощен процесор. Иначе аз го виждам условията да се сведат до индекс и после с този индекс, таблично да си вика съответната функция. Което пак може да се окаже че отнема повече време в крайна сметка.

в общия случай, компилатора (gcc/clang) ще генерира еднакъв код и за двата случая с нещо по-голямо от -О2
нямам наблюдения за мокрочипското компилатор.

Да, и мен ме изненада но е факт. Пробвах така и се оказа с почти 10% по-бавно. Явно индексирането си има цена...

Ами значи нещо концепцията куца Аз вече втора седмица се мъча да измисля нещо да стане ултра елегантно и не ми се получава.

Таблица със всички стойности с които сравняваш свързана с Call-ове към съответното действие , със сигурност победи винаги ще се изпълнява проверката за константно време като цяло при различни стойности винаги времето за изпълнение ще е едно и също .Другия вариант е да го напишеш на VHDL или Verilog ( шегичка).

То така ама ако сравняваш една и съща променлива. Бабане така го е написал, че сякаш е една и съща. Тогава въпросната променлива се прави като индекс на таблица с call-ове. Ще трябва обаче тези които няма как да се появят да присъстват в таблицата по някакъв начин - малко повече код. И щом компилатора не иска да го сдъвче по този начин - инлайн асм...

когато е switch - компилатора прави jump по таблица (не е call)
а когато е с таблица прави call (със съответния овърхед)