c# performance if-statement switch-statement

c# - ¿Es "else if" más rápido que "switch()"?



performance if-statement (14)

¿Por qué te importa?

El 99,99% del tiempo, no debería importarte.

Es improbable que este tipo de microoptimizaciones afecte el rendimiento de su código.

Además, si NECESITA que le importara, debería estar haciendo un perfil de rendimiento en su código. En cuyo caso, la diferencia de rendimiento entre un caso de cambio y un bloque if-else sería trivial.

Edición: para mayor claridad: implemente el diseño que sea más claro y fácil de mantener. En general, cuando se enfrenta a una gran caja de interruptores o si no, la solución es usar polimorfismo. Encuentra el comportamiento que está cambiando y encapsúlalo. He tenido que lidiar con un enorme y feo código de mayúsculas como este antes y en general no es tan difícil de simplificar. Pero oh tan satisfactorio.

Posible duplicado:
¿Hay alguna diferencia significativa entre usar if / else y switch-case en C #?

Soy un ex tipo Pascal, actualmente estoy aprendiendo C #. Mi pregunta es la siguiente:

¿Es el código de abajo más rápido que hacer un cambio?

int a = 5; if (a == 1) { .... } else if(a == 2) { .... } else if(a == 3) { .... } else if(a == 4) { .... } else ....

Y el interruptor:

int a = 5; switch(a) { case 1: ... break; case 2: ... break; case 3: ... break; case 4: ... break; default: ... break; }

¿Cuál es más rápido?

Lo pregunto, porque mi programa tiene una estructura similar (muchas, muchas declaraciones "si no"). ¿Debo convertirlos en interruptores?

Creyendo esta evaluación de desempeño , el caso de cambio es más rápido.

Esta es la conclusión:

Los resultados muestran que la instrucción de cambio es más rápida de ejecutar que la escala if-else-if. Esto se debe a la capacidad del compilador para optimizar la instrucción switch. En el caso de la escalera if-else-if, el código debe procesar cada sentencia if en el orden determinado por el programador. Sin embargo, debido a que cada caso dentro de una declaración de cambio no se basa en casos anteriores, el compilador puede reordenar las pruebas de tal manera que proporcione la ejecución más rápida.

Dado que la instrucción switch expresa la misma intención que su cadena if / else pero de una manera más restringida y formal, su primera suposición debe ser que el compilador podrá optimizarlo mejor, ya que puede sacar más conclusiones sobre las condiciones establecidas. su código (es decir, solo un estado puede ser verdadero, el valor que se compara es un tipo primitivo, etc.) Esta es una verdad general bastante segura cuando se comparan dos estructuras de lenguaje similares para el rendimiento en tiempo de ejecución.

El switch es generalmente más rápido que una larga lista de ifs porque el compilador puede generar una tabla de salto. Cuanto más larga sea la lista, mejor será una sentencia de cambio sobre una serie de sentencias if.

Mucho más importantes que los beneficios de rendimiento del conmutador (que son relativamente leves, pero vale la pena mencionar) son los problemas de legibilidad.

Por mi parte, encuentro una declaración de cambio muy clara en la intención y en los espacios en blanco puros, en comparación con las cadenas de ifs.

No debería ser difícil de probar, cree una función que cambie o, si no es así, entre 5 números, lance un rand (1,5) en esa función y repítalo unas cuantas veces mientras lo cronometra.

No estoy seguro, pero creo que la velocidad de uno u otro cambio depende del lenguaje de programación que esté utilizando.

Normalmente prefiero usar el interruptor. De esa manera el código es simple de leer.

Otra cosa a considerar: ¿es esto realmente el cuello de botella de su aplicación? Hay casos extremadamente raros cuando la optimización de este tipo es realmente necesaria. La mayoría de las veces puede obtener mejores aceleraciones si replantea sus algoritmos y estructuras de datos.

Para unos pocos artículos, la diferencia es pequeña. Si tienes muchos artículos definitivamente debes usar un interruptor.

Si un conmutador contiene más de cinco elementos, se implementa utilizando una tabla de búsqueda o una lista de hash. Esto significa que todos los elementos obtienen el mismo tiempo de acceso, en comparación con una lista de if: s, donde el último elemento tarda mucho más en llegar, ya que tiene que evaluar primero cada condición previa.

Respuesta corta: cambiar la declaración es más rápida

La instrucción if necesita dos comparaciones (cuando ejecuta su código de ejemplo) en promedio para llegar a la cláusula correcta.

La instrucción de cambio, el número promedio de comparaciones, será una independientemente de cuántos casos diferentes tenga. El compilador / VM habrá creado una "tabla de búsqueda" de posibles opciones en el momento de la compilación.

¿Pueden las máquinas virtuales optimizar la instrucción if de una manera similar si ejecuta este código a menudo?

Técnicamente, producen el mismo resultado exacto por lo que deberían ser optimizables de la misma manera. Sin embargo, hay más posibilidades de que el compilador optimice la caja del conmutador con una tabla de salto que los ifs.

Estoy hablando del caso general aquí. Para 5 entradas, el número promedio de pruebas realizadas para los ifs debe ser inferior a 2.5, asumiendo que usted ordena las condiciones por frecuencia. Apenas un cuello de botella sobre el que escribir a menos que esté en un bucle muy ajustado.

switch generalmente se traduce en una tabla de búsqueda por el compilador, si es posible. Entonces, la búsqueda de un caso arbitrario es O (1), en lugar de hacer algunas comparaciones de casos antes de encontrar el que usted desea.

Así que en muchos casos una cadena if / else if será más lenta. Sin embargo, dependiendo de la frecuencia con la que sus casos sean afectados, puede que no haya diferencia.