Evitar el boxeo al pasar en la matriz primitiva de elemento único

Question

Estoy trabajando con una interfaz que toma el tipo Objeto como entrada. Esto es desafortunado para mí ya que tengo datos primitivos que a veces necesito pasar a través de la interfaz. Esto, por supuesto, me obliga a boxear.

El perfilado ha mostrado que esta área es un punto de acceso en el código. Por lo tanto, estoy explorando alternativas para hacer que esta área sea más rápida.

Una idea que tuve hoy para esto es preasignar una matriz primitiva estática, y almacenar el valor primitivo en esto, y luego pasar la matriz (y luego en la implementación de la interfaz, tomar el doble de la array

He escrito algunos códigos para probar esto. Para valores razonablemente altos (10 millones), veo que el método de matriz es SIGNIFICATIVAMENTE más rápido. A medida que aumente el número de iteraciones de mi prueba, los dos converge.

Me pregunto si alguien ha pensado en este enfoque antes, y si hay alguna sugerencia sobre cómo comparar este bien.

Ejemplo de código:

Double data = Double.valueOf(VALUE); 
inst.interface(data); 
//inside interface(Object object)... 
Double data = (Double) object; 
double d = data.value(); 

vs ...

doublearray[0] = VALUE; 
inst.interface(data); 
//inside interface(Object object)... 
double[] data = (double[]) object; 
double d = data[0]; 

Gracias! RB

Answer 1

Me gustaría ir con la opción de matriz, como un solo objeto se asigna cada vez (la matriz), frente al número de veces que se tendría que destinar una en el autoboxing, a pesar de que valueOf() está optimizado para algunos valores.

Answer 2

Una gran diferencia entre el uso de una matriz de un solo elemento frente a la de autoboxing es que la matriz será mutable, lo que en algunos casos puede ser bueno y en otros casos malo. Tener la matriz mutable mejorará el rendimiento en los casos en que sea seguro reutilizar la misma matriz para pasar diferentes variables a los métodos que van a leer los contenidos de la matriz pero no a ninguna referencia a ella. Sin embargo, puede dar lugar a una variedad de errores difíciles de encontrar si el código mantiene una referencia a uno de los arreglos con el fin de persistir en su valor, y algún otro código cambia el valor almacenado en el conjunto.