Аналогия switch

Question

[Ckpyt]

Есть длинный-длинный switch на тысячу с гаком кейзов на парсере пакетов.
Внимание, вопрос:
эффективнее ли такая штука:

char k;
typedef void(*fptr)();
fptr t[65535];


void a(){k='a';}

void b(){k='b';}

void c(){k='c';}

void* (func)();

void main ()
{
        memset(t,0,sizeof(t));
	t[0]=&a;
	t[1]=&b;
	t[2]=&c;
	unsigned short i;
	cin>>i;
//ключевой кусок
	t[i] ? t[i]() : t[i];
	printf("k=%c",k);
//конец ключевого куска
	_getch();
}

Если нет, то что можете посоветовать?

UPD спасибо ixSci за помощь и упрощение кода.

Answer 1

[ixSci]

Ваша «штука» эффективнее как с точки зрения дизайна, так и с точки зреня скорости. switch вообще не лучший выбор.
Только я бы заменил, это

if(t[i]!=NULL){
        g =(void(*)()) t[i];   
        g();   //или g();   - аналогично
        printf("k=%c",k);
    }

на это

t[i] ? t[i]() : t[i];

Comments

[Ckpyt]

Спасибо.
Сейчас вылизываю код с точки зрения синтаксиса.

[Ckpyt]

Ан нет. Не получается.
Пишет —
void* t[256](); — массив функций не разрешен.
либо, если
void* t[256];
1>Hello.cpp(94): error: expression preceding parentheses of apparent call must have (pointer-to-) function type
1> t[i]? t[i](): t[i];
1> ^

[ixSci]

typedef void(*fptr)();
fptr t[256];

[ixSci]

кстати, Вы пометили вопрос хабом C++. Но Ваш код это С и с C++ имеет мало общего. На C++ так не пишут.

[Ckpyt]

Спасибо! Работает! Я не представлял, что typedef'ом можно так обманывать компилятор :-)
У меня на руках сервер. Там много высокоуровневого кода, включая итераторы и аллокаторы, но много и низкоуровневого. Включая ассемблерные вставки.
Сервер достался по наследству, я его изучаю и правлю.
Так что, мне сложно отличить С++ код от кода С.

Answer 2

[jcmvbkbc]

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

Comments

[Ckpyt]

тест:

switch(i){
	case 1:
		i++;
		break;
	case 2:
		i+=2;
		break;
	case 3:
		i+=3;
		break;
	default:
		i+=4;
	}

компилируется в

004010AE: 8B4DFC               mov ecx, [ebp-04]
004010B1: 8BC1                 mov eax, ecx
*switch
004010B3: 48                   dec eax
004010B4: 7419                 je  004010CF
004010B6: 48                   dec eax
004010B7: 740F                 je  004010C8
004010B9: 48                   dec eax
004010BA: 7405                 je  004010C1
004010BC: 83C104               add ecx, 00000004
004010BF: EB13                 jmp 004010D4
*end switch
* Jump:
 004010BA(C) 

004010C1: B906000000           mov ecx, 00000006
004010C6: EB0C                 jmp 004010D4

* Jump:
 004010B7(C) 

004010C8: B904000000           mov ecx, 00000004
004010CD: EB05                 jmp 004010D4

* Jump:
 004010B4(C) 

004010CF: B902000000           mov ecx, 00000002

* Jump:
 004010BF(U), 004010C6(U), 004010CD(U) 

004010D4: 51                   push ecx

[Ckpyt]

Т.е. видим последовательный перебор значений, скорость — O(N).
мой код — O(1).

[agmt]

Значит компилятор подумал, что так эффективнее. Ведь там ещё надо предусмотреть проверку на соответствие границам (а это 2 вычитания и 2 прыжка) (да-да, она может быть необязательной, о чём знает только программист). Попробуйте сделать то же самое, но с 30 case'ами. И флаг -O2. Должно свернуться в нечто, эквивалентное коду в вопросе.

Answer 3

[golovan]

1) о какой эффективности вопрос: быстродействие, размер кода, понятность кода?
2) предложенный код однозначно дополнить проверкой допустимого диапазона i.

Comments

[Ckpyt]

2, да, конечно. Просто это тестовый пример, сделанный мной просто для проверки идеи :-)

1 — Хотелось бы всего и сразу. :-) Но в первую очередь, конечно, быстродействие.

[golovan]

В предложенном случае — будет быстрее, чем свитч и код не надо будет выстраивать под предположения о статистике значений i.
P.S. затратами на вызов функции и возврат пренебрегаем.

[agmt]

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

[ixSci]

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

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

Answer 4

[rasstroen]

Правильный if всегда быстрее чем свитч

Comments

[rasstroen]

stackoverflow.com/questions/445067/if-vs-switch-speed

Answer 5

[rasstroen]

По тестам, что проводил я, грамотно построенный elseif (с самыми часто встречающимися кейсами сверху) на больших объемах отрабатывал намного быстрее аналогичного свитча, которому «самые частые варианты» задать нельзя

(не туда тыкнул, ответ в тред второго комментария)

Comments

[agmt]

Если это ситуация, когда 99% попадает на 1 из вариантов, а всё остальное распределено между 5 другими, то да, соглашусь. Но это уже слишком тонкая оптимизация.

[rasstroen]

Да, я сильно неправ насчет свитча как оказалось, в коде таких конструкций очень мало, только кейс насчет «частых использований» в памяти отложился.