Switch (compilation et perforamance)

Bonjour à tous,

J'essaye d'optimiser au mieux mon programme. J'ai une instruction switch avec plusieurs cas et dans 6 cas précis je dois écrire une fonction "if{...}else{...}". Est ce qu'il est préférable de faire ces tests à l'intérieur de l'instruction switch (et donc avoir 6 occurences de if, même si c'est dans un switch et donc seulemment un cas en particulier est lu) ou de les regrouper à l'extérieur en fonction d'une variable (pas en plus, puisqu'il y en a une pouvant le faire ) et donc de faire le test à chaque step mais après.

Je pense plutôt à le laisser à l'intérieur même si le programme semble plus long. Merci d'avance

le mieux s'est de laisser a l'intérieur pour mieux te retrouver

Laisse à l'intérieur du switch.

L'optimisation, c'est le fait d'alléger les temps de calcul par l'ordinateur.
Le code est plus long, certes, mais en temps réel, l'ordinateur va suivre cette procédure (en simplifiant bien entendu :gniah: ):

Il rencontre un switch. La variable switchée est "_var" par exemple.
Pour "_var", il a plusieurs solutions: 1 ; 2 ; 3 ; 4 et 5 admettons.
Dans le contexte, "_var" est égale à 3.
L'ordinateur va aller exécuter le code qui se trouve après le case 3: jusqu'au prochain break;.
Dans ton cas, il y a une condition, avec un else derrière, du code à l'intérieur des deux.

C'est tout :pac_dr:

Donc l'ordinateur ne va lire que ce qui le concerne, c'est à dire le case 3:, c'est l'avantage du switch

ok je laisse comme ça

je réquisitionne ce topic
c'est plus rapide un switch ou une série de if? car ils revienne tous au m^me non?
if var=1 {}
if var=2{}
if var=3 {}
switch var
1
2
3

Je suis pas sûr, car je n'utilise pas les switch, mais comme ça, je pense qu'il va lire tous les if, ce que ne fera pas le switch

d'après moi c le switch le plus rapide pour les même raison que ???

ben le switch est plus rapide et organisé mais il n'execute qu'une fonction a la fois contrairement aux conditions :/

exemple 1

Code:

{
switch (keyboard_key)
{
case vk_up : {y-=1]
case vk_down : {y+=1]
case vk_left : {x-=1]
case vk_right : {x+=1]
}
}

exemple 2

Code:

{
if keyboard_check(vk_up) {y-=1}
if keyboard_check(vk_down) {y+=1}
if keyboard_check(vk_left) {x-=1}
if keyboard_check(vk_right) {y+=1}
}

dans le premier exemple on aura que 4 direction de mouvement or dans le deuxième on aura 8 direction...

ok merci

Devil37 a écrit:

Laisse à l'intérieur du switch.

L'optimisation, c'est le fait d'alléger les temps de calcul par l'ordinateur.
Le code est plus long, certes, mais en temps réel, l'ordinateur va suivre cette procédure (en simplifiant bien entendu :gniah: ):

Il rencontre un switch. La variable switchée est "_var" par exemple.
Pour "_var", il a plusieurs solutions: 1 ; 2 ; 3 ; 4 et 5 admettons.
Dans le contexte, "_var" est égale à 3.
L'ordinateur va aller exécuter le code qui se trouve après le case 3: jusqu'au prochain break;.
Dans ton cas, il y a une condition, avec un else derrière, du code à l'intérieur des deux.

C'est tout :pac_dr:

Donc l'ordinateur ne va lire que ce qui le concerne, c'est à dire le case 3:, c'est l'avantage du switch

Erreur.
Ce n'est pas comme ça que procède le processeur. On aurait préféré que ce soit ainsi, mais ce n'est pas le cas.

Il regarde tout les "case" un par un, dans l'ordre en comparant avec la valeur à trouver. Il ne "saute" pas directement à la bonne valeur.
En théorie en tout cas. Peu être qu'un compilateur hight tec de chez Intel est capable de compiler de façon intelligente et de faire différemment, genre, par saut dans le code binaire...

Donc au final, une masse de "if else" imbriqué, et un swith case, c'est quasi pareil.

je penses que switch est quand meme plus rapide:

le if (variable=value)
va stocker 2 variables dans le petit processeur interne : le nom de la variable et sa valeur a tester
puis l'ordinateur va repondre soit oui 1 ou non 0

mais quand l'ordinateur execute un switch, il va une fois stocker le petit nom de la variable, et ensuite tester pour chaque valeur, et donc juste devoir restocker une petite valeur dans la memoire

donc en gros en temps de processeur ca donne 2n pour les ifs
et n+1 pour les switchs.

Juste pour montrer que j'avais raison:

http://edi9999.ifrance.com/cbna/if_exemple.gm6
http://edi9999.ifrance.com/cbna/case_exemple.gm6

chez moi le if tourne a 34 fps et la case a 60 fps, alors que c'est la meme structure.
J'avais plutot raison non

Le double a peu près, mais j'ai seulement testé avec les fps dans GM

Il y a pas d'autres facons de tester qu'avec les fps non ?

Bah si, avec la fonction current_time par exempe qui représente le nbre de milisecondes depuis le démarage de l'ordinateur.

Citation :

var time0, time1, tf0, tf1;
time0 = current_time ;

// To code pour tester les if

tf0 = current_time - time0 ;

time1 = current_time ;

// ton code pour tester les case ac switch

tf1 = current_time - time1;

if( tf0 > tf1)
{
show_message("Les Case de switch sont les plus rapides");
}
else
{
show_message("Les if sont les plus rapides");
}

Ah oui , connaissais pas cette fonction

edi9999 a écrit:

Juste pour montrer que j'avais raison:

http://edi9999.ifrance.com/cbna/if_exemple.gm6
http://edi9999.ifrance.com/cbna/case_exemple.gm6

chez moi le if tourne a 34 fps et la case a 60 fps, alors que c'est la meme structure.
J'avais plutot raison non

En faite, le point que l'on a zapper et qui détourne ce que j'ai dis précédemment de la vérité est le faite que le GML est un langage interprété et non compilé. Car à par cela, rien ne peut espliquer un tel écart. Mon raisonnement était valable pour le langage C ou C++ mais pas pour du GML interprété (sachez d'ailleurs qu'il sera sans doute bientot compilé et que les premiers béta ultra privé ont été délivrés par Yoyogames à quelques "élus")

Je viens de tester en C, une boucle de 1 000 000 de case et une boucle de 1 000 000 de ifs prend autant de temps, c-a-d : 7.30 millisecondes

Cher internautes, vous pouvez donc continuer à programmer avec vos longues séries de IF ou votre petite liste de CASE