2012-08-24 14 views
7

Sé que en Java el switch instrucción no debería utilizarse cuando tiene pocos casos, y en este caso es mejor utilizar un if else if.groovy 'switch' vs. 'if' rendimiento

¿Es verdad también para groovy?

¿Cuál es más rendimiento entre estos dos códigos?

myBeans.each{ 
    switch it.name 
    case 'aValue': 
     //some operation 
    case 'anotherValue: 
     //other operations 
} 

o:

myBeans.each{ 
    if(it.name == 'aValue'){ 
     //some operation 
    } 
    else if (it.name =='anotherValue){ 
     //other operations 
    } 
} 
+3

¿Es esto una preocupación real o simplemente una curiosidad? Es poco probable que este sea el cuello de botella de rendimiento en cualquier lugar en una aplicación real. Si realmente sientes curiosidad, ¿por qué no haces algunos análisis y lo averiguas? –

+0

Fue solo una curiosidad saber qué sucede dentro de la JVM cuando uso el _switch_ – rascio

Respuesta

13

En Java, "switch" es más Effient de serie si bloquea porque el compilador genera una instrucción tableswitch donde el objetivo se puede determinar a partir de una tabla de saltos.

En Groovy, el conmutador no está restringido a valores enteros y tiene mucha semántica adicional, por lo que el compilador no puede usar esa función. El compilador genera una serie de comparaciones, al igual que lo haría con los bloques en serie.

Sin embargo, se llama a ScriptBytecodeAdapter.isCase(switchValue, caseExpression) para cada comparación. Esta es siempre una llamada de método dinámico a un método isCase en el objeto caseExpression. Esa llamada es potencialmente más costosa que ScriptBytecodeAdapter.compareEqual(left, right) que se necesita para una comparación si.

Por lo tanto, en Groovy, el interruptor es generalmente más costoso que el de los bloques de serie.

+1

Por curiosidad, ¿sabe qué cambios sobre esto en Groovy 2.0 usando la compilación estática? – cdeszaq

+0

Interesante pregunta, acabo de comprobarlo. Como esperaba, no cambia las llamadas a ScriptBytecodeAdapter. Por lo tanto, aunque @CompileStatic fuerce las invocaciones de métodos estáticos en el método seleccionado, "cambiar" y "si" todavía atraen llamadas de métodos dinámicos a través de ScriptBytecodeAdapter. –

+0

Me pregunto si este no es un lugar para una posible optimización de velocidad. – cdeszaq