settooltiptext - new icon java

Consejos obsoletos de optimización de Java

Question

Hay una serie de sugerencias de rendimiento que el compilador de Java obsoleta y especialmente la optimización guiada por perfiles . Por ejemplo, estas optimizaciones proporcionadas por la plataforma pueden reducir drásticamente (según las fuentes) el costo de las llamadas a funciones virtuales. VM también es capaz de eninear métodos, desenrollar bucles, etc.

¿Cuáles son las otras técnicas de optimización del rendimiento que se implementaron pero que en realidad se han vuelto obsoletas debido a los mecanismos de optimización que se encuentran en las JVM más modernas?

Answer 1

1. "La optimización prematura es la raíz de todo mal" (Donald Knuth)
2. Es útil para optimizar solo los cuellos de botella.
3. Debes analizar el código en cada situación. Quizás pueda reemplazar el TreeSet por un HashSet rápido porque no necesita la función de clasificación o puede usar float en lugar de double (consulte el SDK de Android).
4. Si ninguna técnica lo ayuda, puede intentar reescribir un fragmento de código y llamarlo a través de JNI , para que el código nativo funcione.

Answer 2

1. No llame manualmente al recolector de basura, perjudica el rendimiento en las implementaciones de JVM modernas.
2. Integer en lugar de Long no ahorrará mucho espacio, pero limitará el rango de los números.
3. Evite las clases Enum generadas a mano y use Enum en su lugar. Java 1.5 introdujo Enums reales, úselos.

Answer 3

El modificador final en métodos y parámetros de método no ayuda con el rendimiento en absoluto.

Además, la wiki de Java HotSpot ofrece una buena descripción general de las optimizaciones utilizadas por HotSpot y cómo usarlas de manera eficiente en el código de Java.

Answer 4

En 2001, hice aplicaciones para un teléfono J2ME. Era del tamaño de un ladrillo. Y casi el poder computacional de un ladrillo.

Hacer que las aplicaciones Java se ejecuten de manera aceptable requirieron escribirlas de la manera más procesal posible. Además, la mejora de rendimiento muy grande fue capturar la ArrayIndexOutOfBoundsException para salir de los bucles de todos los elementos en un vector. ¡Piénsalo!

Incluso en Android hay bucles "rápidos" a través de todos los elementos en una matriz y formas "lentas" de escribir lo mismo, como se menciona en los videos de Google IO en la parte interna de dalvik VM.

Sin embargo, en respuesta a su pregunta, diría que es muy inusual tener que micro-optimizar este tipo de cosas en estos días, y lo esperaría en una máquina virtual JIT (incluso la nueva máquina virtual de Android 2.2, que agrega JIT) estas optimizaciones son discutibles. En 2001, el teléfono ejecutó un intérprete de KVM a 33 MHz. Ahora ejecuta dalvik, una máquina virtual mucho más rápida que KVM, de 500MHz a 1500MHz, con una arquitectura ARM mucho más rápida (mejor procesador incluso permitiendo ganancias de velocidad de reloj) con L1, etc. y llega el JIT.

Aún no nos encontramos en el ámbito en el que me sentiría cómodo realizando la manipulación directa de píxeles en Java, ya sea en el teléfono o en el escritorio con un i7, por lo que todavía hay un código normal de todos los días para el que Java no es lo suficientemente rápido. Aquí hay un blog interesante que afirma que un experto ha dicho que Java tiene un 80% de velocidad C ++ para algunas tareas pesadas de CPU; Soy escéptico, escribo código de manipulación de imágenes y veo un orden de magnitud entre Java y nativo para bucles sobre píxeles. Tal vez me estoy perdiendo un truco ...? :RE

Answer 5

Encontré enlaces anteriores obsoletos. Aquí hay uno nuevo sobre la optimización de Java: http://www.appperfect.com/support/java-coding-rules/optimization.html

Answer 6

Es necesario definir las compensaciones de tiempo / memoria antes de comenzar la optimización del rendimiento. Así es como lo hago para mi aplicación crítica de memoria / tiempo (repito algunas respuestas más arriba, para completar):

1. Regla # 1 Nunca haga la optimización del rendimiento en la etapa más temprana de desarrollo. Nunca lo haga si no lo necesita realmente. Si decidió hacerlo, entonces:
2. use el generador de perfiles para encontrar cuellos de botella, revise el código fuente para encontrar las razones de los cuellos de botella;
3. elija la estructura de datos apropiada con la mejor adaptación en las compensaciones de tiempo / memoria definidas;
4. elegir los algoritmos apropiados (por ejemplo, iteración vs recursión, etc.);
5. evite usar objetos sincronizados de la biblioteca de Java, si realmente no lo necesita;
6. evitar la creación de objetos explícita / implícitamente nueva;
7. anula / reimplementa los tipos de datos / algoritmos que vienen con java si y solo si está seguro de que no se ajustan a sus requisitos.
8. Use pruebas pequeñas e independientes para evaluar el rendimiento de las estructuras de datos / algos elegidas.

Answer 7

La gente que reemplaza a String a = "this" + var1 + " is " + var2; con múltiples llamadas a StringBuilder o StringBuffer. En realidad, ya usa StringBuilder detrás de escena.

Answer 8

Al usar x64 JVM con RAM de menos de 32 GB :

La JVM de 64 bits usa un 30% -50% más de memoria en comparación con la JVM de 32 bits debido a los punteros de objetos ordinarios más grandes. Puede reducir mucho este factor usando JDK6 +.

Desde JDK6u6p a JDK6u22 es opcional y se puede habilitar agregando el argumento JVM:

-XX:+UseCompressedOops

Desde JDK6u23 (JDK7 también) está habilitado por defecto. Más información here .