2012-05-11 11 views
11

Mirando al código fuente de la clase java.nio.DirectByteBuffer, he encontrado esto:¿Cuál es el propósito de cambiar el valor int por cero?

if ((length << 0) > Bits.JNI_COPY_TO_ARRAY_THRESHOLD) .... 

Cuál es el propósito de cambiar la longitud de bits cero? ¿Puede ser esta una optimización de rendimiento u otra cosa?

+7

Nunca he visto esa palabra en su título de publicación utilizada como en este contexto. – Marc

+0

Buena pregunta. Eché un vistazo al código fuente y noté que este modismo se usa varias veces. Misterioso. –

+1

Algunos chicos querían comprobar si javac los está eliminando correctamente. –

Respuesta

3

Hacer i << 0 no es operativo. Se evalúa igual que i.

+3

Esto explica el resultado de la operación, pero realmente no explica la pregunta real: ¿por qué escribir código para hacer esto? –

+1

La pregunta era, * cuál es el propósito * y mi respuesta indica que no puede tener un propósito sensato. – aioobe

+1

@mattb - Si va a encontrar una respuesta, vale la pena entender lo que dicen las palabras de la pregunta, literalmente. –

16

Creo que lo he resuelto.

En los JavaDocs clase:

// -- This file was mechanically generated: Do not edit! -- // 

lo que no es la mano codificados. Se generó mediante secuencias de comandos y el guionista no agregó una optimización para el caso cuando la cantidad para cambiar de bit es cero.

+0

Para ShortBuffer, IntBuffer, LongBuffer las compensaciones se multiplican por 2, 4, 8, etc. por desplazamiento a la izquierda. Optimizar el caso << 0 complicaría el código de generación sin ganancia práctica. – AutomatedMike

2

El i << 0 es claramente redundante. No hay una buena razón para que un programador de Java escriba este código deliberadamente.

yo diría que este código es:

  • escrito por alguien que no estaba pensando,
  • escrito por alguien que no entiende lo que hace el operador <<,
  • el resultado de alguna refactorización semi-mecánica, o
  • originalmente producido por algún tipo de generador de código o traductor.

Sin embargo, hay una gran probabilidad de que el bytecode o el compilador JIT optimicen esto, o que no afecte significativamente el rendimiento de todos modos.

Cuestiones relacionadas