java - sobre - Llamar a captadores en un objeto frente a almacenarlo como una variable local(huella de memoria, rendimiento)
psicologia de la memoria pdf (5)
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()));
}
}
Tendría 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));
}
}
Mi entendimiento es que la JVM está optimizada de alguna manera para el código original y, especialmente, para anidar llamadas 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 espacio de memoria, rendimiento, facilidad de lectura / facilidad y otros que no me vienen a la mente en este momento.
Cuando este último fragmento de código se vuelve más ventajoso sobre el primero, es decir, ¿hay algún número (aproximado) de llamadas listType.getDescription() cuando se usa una variable local temporal? operaciones para almacenar this objeto?
Casi siempre preferiría la solución variable local.
Huella de memoria
Una sola variable local cuesta 4 u 8 bytes. Es una referencia y no hay recursión, así que ignorémosla.
Actuación
Si se trata de un captador simple, la JVM puede memorizarlo por sí misma, 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, casi no importa, ya que el nombre de la variable local es característico en cuanto a caracteres, tan largo como el método de llamada, pero para algo más complicado, es legible ya que no tiene que encontrar las 10 diferencias entre las dos expresiones. Si sabe que son iguales, entonces deje en claro el uso de la variable local.
Exactitud
Imagine que su SelectItem no acepta null s y su programa es multiproceso. El valor de listType.getDescription() puede cambiar mientras tanto y estás tostado.
Depuración
Tener una variable local que contenga un valor interesante es una ventaja.
Lo único que se 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
- no es posible la modificación concurrente
- simple final privado getter
Creo que la forma número dos es definitivamente mejor porque mejora la legibilidad y la capacidad de mantenimiento de su código, que es lo más importante aquí. Este tipo de microoptimización no te ayudará en nada a menos que escribas una aplicación en la que cada milisegundo sea importante.
En el contexto de los lenguajes imperativos, el valor devuelto por una llamada de función no puede memorizarse (consulte http://en.m.wikipedia.org/wiki/Memoization ) porque no hay garantía de que la función no tenga efectos secundarios. En consecuencia, su estrategia sí evita una llamada de función a costa de asignar una variable temporal para almacenar una referencia al valor devuelto por la llamada de 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 la mejor legibilidad del código.
Estaría de acuerdo con el enfoque de la variable local para facilitar la lectura solo si el nombre de la variable local es autodocumentado. Llamarlo "descripción" no sería suficiente (¿qué descripción?). Llamarlo "selectableListTypeDescription" lo dejaría claro. Me gustaría agregar que la variable incrementada en el bucle for debería llamarse "selectableListType" (especialmente si el "listTypeManager" tiene accesores para otros ListTypes).
La otra razón sería si no hay garantía de que esto sea de un solo hilo o que su lista sea inmutable.
No estoy seguro de que ninguno sea el preferido. Lo que preferiría es un código claramente legible sobre un código de rendimiento, especialmente cuando esa ganancia de rendimiento es insignificante. En este caso, sospecho que no hay una diferencia notable (especialmente dadas las optimizaciones de JVM y las capacidades de reescritura de código)