Optimización prematura en Java: cuándo usar "x = foo.getX()" vs simplemente "foo.getX()"

Question

Cuando me encuentro llamando al mismo método getter varias veces, ¿debería considerarse un problema? ¿Es mejor [siempre] asignar a una variable local y llamar solo una vez?

Estoy seguro de que la respuesta por supuesto es "depende".

Estoy más preocupado por el caso más simple en el que el getter es simplemente un método de tipo "transmite el valor de una variable privada". es decir, no hay cálculos costosos involucrados, no se consumen las conexiones de bases de datos, etc.

Mi pregunta de "es mejor" se refiere a la legibilidad del código (estilo) y también al rendimiento. es decir, es que mucho de un impacto en el rendimiento que tienen:

SomeMethod1(a, b, foo.getX(), c); 
SomeMethod2(b, foo.getX(), c); 
SomeMethod3(foo.getX()); 

vs:

X x = foo.getX(); 
SomeMethod1(a, b, x, c); 
SomeMethod2(b, x, c); 
SomeMethod3(x); 

que dan cuenta de esta pregunta es un poco puntillosos y gris. Pero me acabo de dar cuenta, no tengo una manera consistente de evaluar estos intercambios, en absoluto. Estoy buscando algunos criterios que son más que completamente caprichosos.

Gracias.

Answer 1

La elección no debería ser realmente sobre el rendimiento alcanzado sino sobre la legibilidad del código.

Cuando crea una variable, puede darle el nombre que merece en el contexto actual. Cuando usa el mismo valor más de una vez, seguramente tiene un significado real, más que un nombre de método (o peor una cadena de métodos).
Y es realmente mejor leer:

String username = user.getName(); 
SomeMethod1(a, b, username, c); 
SomeMethod2(b, username, c); 
SomeMethod3(username); 

que

SomeMethod1(a, b, user.getName(), c); 
SomeMethod2(b, user.getName(), c); 
SomeMethod3(user.getName()); 

Answer 2

La mayoría de las veces usaría getX si solo fuera una vez y creara una var para todos los demás casos. A menudo solo para guardar la escritura.

Con respecto al rendimiento, el compilador probablemente podría optimizar la mayor parte de la sobrecarga, pero la posibilidad de efectos secundarios podría forzar al compilador a trabajar más al hacer múltiples llamadas a métodos.

Answer 3

Para captadores simples, aquellos que simplemente devuelven un valor, HotSpot lo inscribe en el código de llamada, por lo que será tan rápido como sea posible.

Yo, sin embargo, tengo el principio de mantener una declaración en una sola línea, lo que muy a menudo hace que expresiones como "foo.getBar()" sean demasiado largas para caber. Entonces, para mí, es más legible extraerlo a una variable local ("Bar bar = foo.getBar()").

Answer 4

Pueden ser 2 cosas diferentes.

Si GetX es no determinista, entonces el primero uno va a dar resultados diferentes que el segundo

En lo personal, me gustaría usar el segundo uno. Es más obvio y menos innecesariamente detallado.

Answer 5

Puedo usar el segundo estilo si se hace el código más legible o si tengo que usar el valor asignado de nuevo. Nunca considero el rendimiento (en cosas triviales) a menos que sea necesario.

Answer 6

Eso depende de lo que getX() realmente hace. Considere esta clase:

public class Foo { 
    private X x; 

    public X getX() { return x; } 
} 

En este caso, cuando se hace una llamada a foo.getX(), JVM optimizará todo el camino hasta foo.x(como en referencia directa a foo 's ámbito privado, básicamente, un puntero de memoria). Sin embargo, si la clase es el siguiente:

public class Foo { 
    private X x; 

    public X getX() { return cleanUpValue(x); } 

    private X cleanUpValue(X x) { 
     /* some modifications/sanitization to x such as null safety checks */ 
    } 
} 

la JVM no puede en realidad inline la manera más eficiente ya que por más Foo 's contrato de construcción, se tiene que desinfectar x antes de entregarla a cabo.

En resumen, si getX() realmente no hace nada más que devolver un campo, entonces no hay diferencia después de que la optimización inicial se ejecute en el bytecode en si llama al método una o más veces.

Answer 7

Dos cosas tienen que ser considerados:

1. ¿La llamada a getX() tiene efectos secundarios? Siguiendo los patrones de codificación establecidos, un getter no debe alterar el objeto al que se llama, en la mayoría de los casos, no hay ningún efecto secundario. Por lo tanto, es semánticamente equivalente llamar al getter una vez y almacenar el valor localmente contra llamar al getter varias veces. (Este concepto se denomina idempotencia: no importa si llama a un método una o varias veces, el efecto en los datos es exactamente el mismo).

2. Si el captador no tiene ningún efecto secundario, el compilador puede eliminarlo con seguridad llamadas posteriores al comprador y crear el almacenamiento local temporal por sí mismo, por lo tanto, el código sigue siendo legible y tiene toda la ventaja de velocidad de llamar al getter solo una vez. Esto es aún más importante si el captador no solo devuelve un valor sino que tiene que buscar/calcular el valor o ejecutar algunas validaciones.

Asumiendo que su captador no cambia el objeto sobre el que opera es probable que sea más fácil de leer para tener varias llamadas a getX() - y gracias al compilador que no tiene que el desempeño del comercio para mejorar la legibilidad y facilidad de mantenimiento.

Answer 8

general I almacenar de forma local si:

1. Estoy va a usar en un bucle y no quiero o espero que el valor cambie durante el bucle.

2. Estoy a punto de usarlo en una larga línea de código o la función & Los parámetros son muy largos.

3. Quiero cambiar el nombre de la variable para que se corresponda mejor con la tarea en cuestión.

4. Las pruebas indican un aumento significativo en el rendimiento.

De lo contrario, me gusta la posibilidad de obtener valores actuales y un nivel más bajo de abstracción de las llamadas a métodos.