2009-12-02 10 views
8

Tengo una aplicación Java que se empaqueta con JarBundler. La aplicación consume bastante CPU (muchas llamadas grandes Collection.sort()).Java VM de 64 bits ejecuta la aplicación 10 veces más lento

En Mac OS, la aplicación funciona lenta y lentamente cuando se utiliza JavaApplicationStub de 64 bits. Este archivo JavaApplicationStub está lanzando la máquina virtual de Java de 64 bits.

Encontré un viejo archivo JavaApplicationStub que solo es de 32 bits. Lo reemplacé en el paquete, ¡y la aplicación funciona 10 veces más rápido! (en consecuencia, la máquina virtual de 32 bits se utiliza cuando se ejecuta la aplicación).

¿Tiene esto sentido? ¿Por qué la VM de 64 bits es mucho más lenta? ¿Tiene sentido construir una aplicación y hackear el archivo JavaApplicationStub de esta manera?

Aconsejar es apreciado.

+2

Apenas llegando, pero lo que es el hardware se está ejecutando en? –

+1

Especialmente la cantidad de memoria que tiene. Verifique con el visor de actividades si la máquina está intercambiando. –

+0

Ejecutarlo en MacBook Core 2 Duo 10.5.8 – craiglurey

Respuesta

5

Consulte this post sobre los beneficios/desventajas de ejecutar una JVM de 64 bits. En resumen, la desreferenciación de punteros & la desasignación de memoria puede llevar más tiempo y se está moviendo alrededor de estructuras de datos más grandes (es decir, 64, no 32 bits, lo que no le beneficia a menos que haga uso explícito de ellos).

Véase también this relevant article, donde se discuten las disminuciones en el rendimiento de hasta un 85% cuando se mueve a 64 bits, lo cual está en línea con lo que está experimentando:

La razón de esta disminución en el rendimiento es en realidad muy relacionado con el aumento de la memoria. Las referencias de memoria bajo las cubiertas de Java se han duplicado, lo que aumenta el tamaño de las estructuras de memoria en el tiempo de ejecución de WAS y los objetos de su aplicación. Lamentablemente, los tamaños de la memoria caché de la memoria del procesador no aumentaron al mismo tiempo. Esto significa que se pierde más memoria caché, lo que significa un trabajo más ocupado para el hardware que trata con la memoria más grande, lo que significa un peor rendimiento de la aplicación.

+1

Entonces, si la respuesta es aferrarse a 32 bits, entonces, ¿cuál es la mejor manera de hacer cumplir esto? ¿Debería JavaApplicationStub revertirse a la versión de 32 bits, o debería ejecutarse con diferentes parámetros de VM? – craiglurey

+0

No soy un usuario de JavaApplicationStub/mac y no pude encontrar ningún documento relacionado con él, pero en el estándar Sun jvm no hay una opción 'ejecutar 64 bits jvm en modo 32 bits' por lo que puedo decir (http: //java.sun.com/javase/technologies/hotspot/vmoptions.jsp#BehavioralOptions) así que solo usa la compilación de 32 bits, si puedes. – Joel

-1

64 bit no es más lento. Probar:

public class Benchmark { 
public static void main(String args[]) { 
long time = System.currentTimeMillis(); 
for (int a = 1; a < 900000000; a++) { 
    for (int b = 1; b < 20; b++) { 
    } 
} 
long time2 = System.currentTimeMillis() - time; 
System.out.println("\nTime counter stopped: " + time2); 

}

en 32 y 64 y nos dicen los resultados que obtiene

Cuestiones relacionadas