Estoy escribiendo un programa Java que requiere miles de instrucciones System.out.println() que se imprimirán cientos de millones (o miles de millones) de veces a lo largo del ciclo de vida del programa con fines de depuración:
if (GVar.runInDebugMode) System.out.println("Print debug message");En el mundo real, estas declaraciones se pueden desactivar para acelerar un cálculo computacional pesado.
Si configuro:
public final static boolean runInDebugMode = false; ¿El compilador vuelve a evaluar runInDebugMode cada vez que se encuentra con una declaración como: if (GVar.runInDebugMode) o dado que se declaró como final, se evaluará una vez al comienzo del programa y no ejercerá una presión adicional sobre la CPU? ? En otras palabras, ¿sería mejor comentar todas las declaraciones de depuración por completo una vez que implemente la aplicación o configurar runInDebugMode en false ?
El escenario que tiene se describe como "compilación condicional", es decir, el compilador que produce el código de bytes puede optimizar el código si la variable constante es falsa :
"... para permitir que la declaración if se use convenientemente para fines de "compilación condicional", las reglas reales difieren.
Como ejemplo, la siguiente declaración da como resultado un error en tiempo de compilación:
while (false) { x=3; }porque el enunciado x=3; no es accesible; pero el caso superficialmente similar:
if (false) { x=3; } no da como resultado un error en tiempo de compilación. Un compilador optimizador puede darse cuenta de que la sentencia x=3; nunca se ejecutará y puede elegir omitir el código para esa declaración del archivo de class generado , pero la declaración x=3; no se considera "inalcanzable" en el sentido técnico especificado aquí".
Tenga en cuenta la parte en negrita: depende del compilador, pero es bastante fácil de verificar con el desensamblador de javap , simplemente ejecute javap -v -l -p MyClass.class para ver el código de bytes resultante. Estoy bastante seguro de que Oracle/OpenJDK javac hace esa optimización desde hace mucho tiempo, al igual que la mayoría de los compiladores. Tenga en cuenta que GVar.runInDebugMode es una expresión constante , por lo que se beneficia de esta optimización.
"La compilación condicional viene con una advertencia. Si se compila un conjunto de clases que usan una variable de "bandera", o más precisamente, cualquier variable constante estática (§4.12.4), y se omite el código condicional, no es suficiente más tarde para distribuir solo una nueva versión de la clase o interfaz que contiene la definición de la bandera. Las clases que usan la bandera no verán su nuevo valor, por lo que su comportamiento puede ser sorprendente. En esencia, un cambio en el valor de una bandera es binario compatible con binarios preexistentes (no se produce LinkageError) pero no compatible desde el punto de vista del comportamiento".
que básicamente dice que también debe volver a compilar el código que usa la bandera, además de la clase que la define. Esto no debería ser un problema si compila todo el código.