Bonjour les habitués!
Je me disais : plutot que de faire un switch case, je vais faire un tableau de pointeurs sur fonctions membres, et ça va être plus rapide. Ce n'est pas le cas : le calcul avec switch/case est deux fois plus rapide. Pourquoi? Le problème n'a pas l'air d'exister si tout ça se fait à l'extérieur d'une classe.
 
 

dans le cas avec le switch tu fait un appel direct à une fonction définie directement dans la classe -> inline.
 
Avec un pointeur sur fonction membre placé dans un vector ça devient beaucoup moins facile pour le compilo de savoir qu'il peut faire cet inline ....

 
Et je ne peux rien faire pour l'aider?

Garde ton switch tout simplement

 
Oui, c'est ce que je vais faire... J'avais pensé à ça en me disant que je pouvais éviter des pages et des pages de switch.
Tant pis  

Un tableau fait autant de lignes que le switch en gros normalement ....
 
Si jamais t'es sous GCC, que la portabilité du code t'inquiète pas trop et que tu as des séries de valeurs de switch qui appellent la même fonction tu peut utiliser des range.

c'est une contre-optimisation votre truc car le contexte est bidon.
 
bien sûr si chaque fonction fait 0 ou 1 instruction assembleur (j'adore le res+=0), t'y gagne a faire un gros switch dégueulasse avec la seule instruction inlinée, plustôt qu'un call.
mais avec une fonction qui fait pas juste que nopper, le call depuis un tableau sera insignifiant, et passé un certain nombre de cas de switch, le call sera bien plus économique.
 
change tes res+= par des vraies fonctions (avec des boucles des machins et des bidules), et mets 16,20 fonctions tu vas voir le comportement va s'inverser.

 
Je suis pas trop d'accord, y'a de grandes chances que le switch ( à partir d'une certaine taille et si y'a pas de gros trou vers des valeurs importantes ) soit traduit par le compilo par un tableau, dans ce cas tu garde le temps d'accès constant quelque soit le nombre de switch ET la possibilité d'inliner. Je vois pas trop dans quelle situation alors le déréférencement de pointeur de fonction membre + le call peut alors être moins couteux, par contre j'ai vraiment l'impression que le tableau est une "optimisation" faite main de ce que le compilo ferait, en moins bien à cause de la difficulté accrue d'analyse des pointeurs pour le compilo.
 
( Sinon effectivement le contexte de test est bidon tant qu'il n'est pas exactement la chose qui sera exécutée )

moi je préfère calc1. Je vois l'intérêt de l'inline ici que parce que les méthodes sont minuscules. Sinon, si elle était de taille plus normale, voire virtuelle, ça n'aurait strictement aucun intérêt.
 
Mais ici le problème, c'est bien que t'as 6 fonctions qui font la même chose à une nuance pres. fais un void f(int inc) { res += inc; } et voilà.

 
 
on est d'accord que si tu gardes des entiers contigus, le compilo peut utiliser une table de jumps avec les fonctions inlinées.
mais à la moindre irrégularité des cas de switch, le compilo doit basculer vers des tests classiques.
bon après si son cas c'est d'avoir que des case contigus, ça peut être bien, mais à vérifier avec la sortie asm.
 
mais bon avec des vrais fonctions qui font plus de 10 cycles d'horloge, le call du tableau sur les fonctions non inlinées sera déjà moins notable.