Llamar getters en un objeto vs. almacenarlo como una variable local (huella de memoria, rendimiento)

En el siguiente fragmento de código hacemos una llamada listType.getDescription() dos veces:

 for (ListType listType: this.listTypeManager.getSelectableListTypes()) { if (listType.getDescription() != null) { children.add(new SelectItem( listType.getId() , listType.getDescription())); } } 

Tiendo a refactorizar el código para usar una sola variable:

 for (ListType listType: this.listTypeManager.getSelectableListTypes()) { String description = listType.getDescription(); if (description != null) { children.add(new SelectItem(listType.getId() ,description)); } } 

Según entiendo, la JVM está optimizada de algún modo para el código original y especialmente para las llamadas de anidación como children.add(new SelectItem(listType.getId(), listType.getDescription())); .

Comparando las dos opciones, ¿cuál es el método preferido y por qué? Eso es en términos de huella de memoria, rendimiento, legibilidad / facilidad y otros que no se me vienen a la mente en este momento.

¿Cuándo el último fragmento de código se vuelve más ventajoso que el anterior, es decir, hay alguna cantidad (aproximada) de llamadas a listType.getDescription() cuando se usa una variable local temporal que se vuelve más deseable, ya que listType.getDescription() siempre requiere alguna stack operaciones para almacenar this objeto?

Casi siempre preferiría la solución de variable local.

Huella de memoria

Una sola variable local cuesta 4 u 8 bytes. Es una referencia y no hay recursión, así que ignóremosla.

Actuación

Si se trata de un getter simple, la JVM puede memorizarlo, por lo que no hay diferencia. Si es una llamada costosa que no se puede optimizar, la memorización manual la hace más rápida.

Legibilidad

Sigue el principio DRY . En su caso, apenas importa, ya que el nombre de la variable local es característico tanto como la llamada al método, pero para algo más complicado, es la legibilidad ya que no tiene que encontrar las 10 diferencias entre las dos expresiones. Si sabes que son iguales, hazlo claro usando la variable local.

Exactitud

Imagine que su SelectItem no acepta null s y su progtwig es multiproceso. El valor de listType.getDescription() puede cambiar mientras tanto y estarás tostado.

Depuración

Tener una variable local que contenga un valor interesante es una ventaja.


Lo único que gana al omitir la variable local es guardar una línea. Así que lo haría solo en los casos en que realmente no importa:

  • expresión muy corta
  • ninguna posible modificación concurrente
  • simple getter final privado

Creo que la forma número dos es definitivamente mejor porque mejora la legibilidad y el mantenimiento de su código, que es lo más importante aquí. Este tipo de micro-optimización no te ayudará en nada a menos que estés escribiendo una aplicación donde cada milisegundo es importante.

No estoy seguro de que sea preferido. Lo que preferiría es código claramente legible sobre código de rendimiento, especialmente cuando esa ganancia de rendimiento es insignificante. En este caso, sospecho que no hay una diferencia notable (especialmente teniendo en cuenta las optimizaciones de JVM y las capacidades de reescritura de código)

En el contexto de lenguajes imperativos, el valor devuelto por una llamada a función no puede ser memorizado (Ver http://en.m.wikipedia.org/wiki/Memoization ) porque no hay garantía de que la función no tenga ningún efecto secundario. En consecuencia, su estrategia efectivamente evita una llamada a la función a expensas de asignar una variable temporal para almacenar una referencia al valor devuelto por la llamada a la función. Además de ser un poco más eficiente (lo que realmente no importa a menos que la función se llame muchas veces en un bucle), optaría por su estilo debido a una mejor legibilidad del código.

Estoy de acuerdo con el enfoque de variable local para la legibilidad solo si el nombre de la variable local es autodocumentado. Llamarlo “descripción” no sería suficiente (¿qué descripción?). Llamarlo “seleccionableListaTipoDescripción” lo dejaría en claro. Yo agregaría que la variable incrementada en el bucle for debería llamarse “listaLista seleccionable” (especialmente si el “listTypeManager” tiene acceso para otros ListTypes).

La otra razón sería si no hay garantía de que sea de un solo hilo o que su lista sea inmutable.

Intereting Posts