rapidité du switch vs if/else
Bonjour,
de la discussion suivante
Pourquoi fact_res_1 est-elle plus rapide que fact_res_2 ?
j'ai appris que
Citation:
Le switch étant [légèrement] + efficace parce qu'il utilise 1 table de sauts
Après une légère recherche, une table de saut (ou table de correspondance/Lookup table) est une liste d'associations de valeurs.
Comment dans le cas d'un test tel que, if (n == 1) ou if (n != 1) une telle table peut-elle être construit ?
ça ne va quand même pas faire un tableau de n cases avec faux à toutes les cases sauf la première pour if (n == 1) et un tableau de n cases avec vrai à toutes les cases sauf la première pour if (n != 1).
Car dans ce cas:
ce mécanisme ne pouvant s'appliquer qu'à l’exécution (la valeur de n étant inconnu à la compilation).
le travail à effectuer, n comparaisons, pour créer la table n'est-il pas équivalent aux n tests ( (n == 1) / (n !*= 1) ) ? donc implique un coût identique.
la seule manière de "rentabilise" la création de cette table serait un accès fréquent à la fonction contenant le test (double récurrence ou autres).
À cela il faudrait ajouter le coût de la place en mémoire ainsi que son accès (tests if-else dans les registre du CPU Vs accès en RAM voir mémoire virtuelle).
Seul si le calcul, dans la comparaison, est une formule compliquer voir un appel de fonction, il semble y avoir un bénéfice.
A cela on peut ajouter le cas suivant:
version if-else
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| if(A) {
do 1;
}
then if (B) {
do 2;
}
then if (C) {
do 3;
}
else {
do 4;
} |
version switch
Code:
1
2
3
4
5
6
7
8
9
10
11
| switch(c) {
case(A):
do 1;
case(B):
do 2;
case(C):
do 3;
default:
do 4;
} |
si le cas (A) est à 98% celui qui est rencontré
dans le cas du if, (B) et (C) ne seront quasiment jamais calculés et le switch s’embarrasse d'une table ne lui servant à presque rien.
Tout ceci n’étant que supposition il en demeure une autre: si le swith et plus optimal que if-else le compilateur n'aurait-il pas intérêt à transformer les if-else en switch.
