viernes
jul012005
Mitos sobre el rendimiento de Java (Azul Systems)
viernes, julio 1, 2005 at 1:33PM
Cliff Click, de Azul Systems enumerý en JavaOne una serie de mitos sobre prácticas que influyen en el rendimiento de la ejecucrión de código Java. El problema de dichos mitos es que su seguimiento "empeora" la legilibilidad del código injustificadamente.
En resumen:
1) Los métodos "final" hacen más rýpido el código que sin dicha palabra clave (métodos virtuales). Falso.
2) Los bloques try/catch o no influyen o influyen mucho en el rendimiento. Ambos son errýneos como mýximas, depende, en el ýmbito de bucles pueden ser costosos en otros casos no.
3) Usar Run-Time Type Info (instanceof) mejor que llamar a métodos virtuales. Ambos son comparables, el RTTI da lugar a código más "feo".
4) La sincronizacrión es muy lenta. No es cierto, tiene impacto pero pequeño y con los aráos cada vez menor.
5) Usar pools de objetos reusables en vez de crear nuevos y dejar al garbage colector liberarlos. La primera opcrión es problemýtica cuando hay varios hilos al necesitar sincronizarse la coleccrión disminuyendo el rendimiento buscado, complica además el programa. Es "rentable" en grandes colecciones de objetos.
6) Las mejoras introducidas en la Java Platform Standard Edition 5.0 son costosas en rendimiento. No es cierto, enums, autoboxing y varargs no influyen en el rendimiento. Sýlo el método values() de los enums es lento.
¿Y tu que opinas? ýutilizas estas prácticas de mejora del rendimiento?
En resumen:
1) Los métodos "final" hacen más rýpido el código que sin dicha palabra clave (métodos virtuales). Falso.
2) Los bloques try/catch o no influyen o influyen mucho en el rendimiento. Ambos son errýneos como mýximas, depende, en el ýmbito de bucles pueden ser costosos en otros casos no.
3) Usar Run-Time Type Info (instanceof) mejor que llamar a métodos virtuales. Ambos son comparables, el RTTI da lugar a código más "feo".
4) La sincronizacrión es muy lenta. No es cierto, tiene impacto pero pequeño y con los aráos cada vez menor.
5) Usar pools de objetos reusables en vez de crear nuevos y dejar al garbage colector liberarlos. La primera opcrión es problemýtica cuando hay varios hilos al necesitar sincronizarse la coleccrión disminuyendo el rendimiento buscado, complica además el programa. Es "rentable" en grandes colecciones de objetos.
6) Las mejoras introducidas en la Java Platform Standard Edition 5.0 son costosas en rendimiento. No es cierto, enums, autoboxing y varargs no influyen en el rendimiento. Sýlo el método values() de los enums es lento.
¿Y tu que opinas? ýutilizas estas prácticas de mejora del rendimiento?
in
j2se
j2se 
Reader Comments