¿Hay alguna razón por qué decir que tan costosa es la operación del procesador en milisegundos o fracasos? Me interesaría en "instanceof", yesos (escuché que son muy "caros").Costos de operaciones en Java
¿Hay algunos estudios al respecto?
Dependerá de qué JVM esté utilizando, y el costo de muchas operaciones puede variar incluso dentro de la misma JVM, dependiendo de la situación exacta y de la optimización que haya realizado el JIT.
Por ejemplo, una llamada de método virtual todavía puede ser insertada por el JIT de zona activa, siempre que no haya sido reemplazado por otra cosa. En algunos casos, con el servidor JIT puede todavía estar incluido con una prueba de tipo rápido, para un par de tipos.
Básicamente, los JIT son tan complejos que es poco probable que haya una respuesta significativa de propósito general a la pregunta. Debe comparar su propia situación específica en el mundo real de la mejor manera posible. Debería generalmente escribir código con objetivos primarios de simplicidad y legibilidad, pero medir el rendimiento regularmente.
El tiempo en el que las instrucciones o los ciclos de recuento pueden darle una buena idea sobre el rendimiento de algún código han desaparecido, gracias a muchas optimizaciones que suceden en todos los niveles de ejecución del software.
Esto es especialmente true para lenguajes basados en VM, donde la JVM simplemente puede omitir algunos pasos porque sabe que no es necesario.
Por ejemplo, hace tiempo que leí en un artículo (intentaré encontrarlo y lo vinculo eventualmente) que estos dos métodos son bastante equivalentes en costo (en la HotSpot JVM, es decir):
public void frobnicate1(Object o) {
if (!(foo instanceof SomeClass)) {
throw new IllegalArgumentException("Oh Noes!");
}
frobnicateSomeClass((SomeClass) o);
}
public void frobnicate2(Object o) {
frobnicateSomeClass((SomeClass) o);
}
Obviamente el primer método tiene más trabajo, pero la JVM sabe que el tipo de o ya se ha comprobado en el if y en realidad puede saltar del tipo a comprobar en el modelo más adelante y hacer que se un no-op.
Esta y muchas otras optimizaciones hacen que el conteo de "fracasos" o ciclos sea prácticamente inútil.
En general, un cheque instanceof es relativamente barato. En HotSpot JVM se reduce a una verificación numérica del tipo id en el encabezado del objeto.
This classic article describe por qué debería "Escribir Código Estúpido".
También hay un artículo de 2002 que describe how instanceof is optimized in the HotSpot JVM.
Una vez que la JVM se ha calentado, la mayoría de las operaciones se pueden contar en nano segundos (millonésimas de mili-segundo) Cuando se habla de algo caro, generalmente hay que decir que es caro en comparación con una alternativa. Es casi imposible describir algo tan caro en todos los casos.
Normalmente, el gasto más importante es su tiempo (y otros desarrolladores en su equipo) Usar instanceof puede ser costoso en desarrollo y tiempo de soporte de código porque a menudo indica un diseño deficiente. Usar técnicas de POO adecuadas suele ser una mejor idea.Los 10 nano segundos que podría tomar un instanceof, generalmente son relativamente triviales.
El costo de las operaciones específicas realizadas dentro de la CPU casi nunca es relevante para el rendimiento. Si el rendimiento es malo, casi siempre se debe a IO (red, disco) o código ineficiente. Escribir un código eficiente es mucho más acerca de encontrar una manera de reducir la cantidad total de operaciones en lugar de evitar operaciones "costosas" (excepto aquellas que son órdenes de magnitud más costosas, como IO).
Esto depende de la implementación de la máquina virtual y la arquitectura del procesador subyacente, y potencialmente de otras cosas. –