Hay una forma correcta de pasar argumentos en slf4j?

Estoy usando slf4j para el seguimiento de la información. Mi código es

private static final Logger log = LoggerFactory.getLogger(ObjectTest.class);

log.trace("Time taken to store " + count
            + " objects of size " + size +  " is " + (time) + " msecs");

log.trace("Time taken to store {} objects of size {} is {} msecs",
        new Object[] { count, size, time });

log.trace("Time taken to store {} objects of size {} is {} msecs",
        count, size, time);

Que sería el mecanismo preferido para el registro de las huellas.

  • 3 no se compila. El varargs sintaxis permitiría 3 sin embargo (si he entendido bien). El informe de error para el que está en bugzilla.slf4j.org/show_bug.cgi?id=31
  • Si que es un verdadero bucle estrecho, y el rendimiento es crítico, se debe envolver el registro de comando en if (log.isTraceEnabled()) {... declaración
InformationsquelleAutor diya | 2011-08-18

3 Kommentare

  1. 55

    3 es la mejor.

    3 y 2 generar la misma (o casi la misma) bytecode, pero 3 es más fácil de escribir y es más corto, así que 3 es mejor que el 2.

    Si el seguimiento no está habilitado, 1 debe realizar la concatenación de cadenas («el Tiempo tomado para almacenar» + cantidad + ….) que es un poco caro, mientras que la 2 no la concatenación de cadenas sólo si el seguimiento está habilitado, que es la razón por la 3 es mejor que 1.

    • 3 no se compila.
    • Compila para la versión más reciente de slf4j.
  2. 30

    3 es mejor, excepto que no es compatible en SLF4J 1.6.x. Para tres o más argumentos que necesita el segundo formulario. La tercera forma sólo funciona con uno o dos argumentos (pero no tres o más).

    Como de SLF4J 1.7, la tercera forma es ahora compatible con 3 o más argumentos. El compilador de java en silencio se transforma invocaciones con 3 o más argumentos a la segunda forma, pasando de un Objeto[] para el método de impresión. Este es un detalle de implementación de varargs en Java y permite SLF4J 1,7 a ser 100% compatible con SLF4J 1.6.

    • ¿sabes si esto es cierto. Estaba leyendo el blog siguiente en JMH y se me hizo curioso: antoniogoncalves.org/2015/01/15/…
    • Buen artículo. No creo que el artículo se contradice con la anterior, es decir, el costo de la construcción de Object[] ha disminuido y es simplemente un problema menor.
  3. 7

    La 3ª variante es la mejor.

    De hecho, 1er caso es una concatenación de cadenas a través de StringBuilder.

    La 2ª y la 3ª de los casos son los mismos.
    Ellos necesitan cuadro de valores de entero a Entero (u otro Objeto) y, a continuación, crear una matriz para empacar.

    La simple prueba en mi máquina de decir que la 3ª variante es mejor en alrededor de 8 veces en el caso de que el registro no ejecutado (56ns vs 459ns).

    public class LogTest {
        private static final Logger logger = LoggerFactory.getLogger(LogTest.class);
    
        public static void main(String[] args) {
            int size = 100_000_000;
    
            long start = System.nanoTime();
            for (int i = 0; i < size; i++) {
                logger.trace("1 {} 2 {} 3 {}", i, i, i);
            }
            System.out.println((System.nanoTime() - start) / size);
    
            start = System.nanoTime();
            for (int i = 0; i < size; i++) {
                logger.trace("1 " + i + " 2 " + i + " 3 " + i);
    
            }
            System.out.println((System.nanoTime() - start) / size);
        }
    }

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea