Logger slf4j avantages du formatage avec {} au lieu de la concaténation de chaînes

Y a-t-il un avantage à utiliser {}au lieu de la concaténation de chaînes?

Un exemple de slf4j

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

au lieu de

logger.debug("Temperature set to"+ t + ". Old temperature was " + oldT);

Je pense que c'est une question d'optimisation de la vitesse, car l'évaluation des paramètres (et la concaténation de chaînes) pourraient être évitées au moment de l'exécution en fonction d'un fichier de configuration. Mais seuls deux paramètres sont possibles, alors parfois il n'y a pas d'autre choix que la concaténation de chaînes. Besoin de points de vue sur cette question.

Il s'agit de performances de concaténation de chaînes. C'est potentiellement important si vous avez des instructions de journalisation denses.

(Avant SLF4J 1.7) Mais seuls deux paramètres sont possibles

Comme la grande majorité des instructions de journalisation ont 2 paramètres ou moins, l'API SLF4J jusqu'à la version 1.6 couvre (uniquement) la majorité des cas d'utilisation. Les concepteurs d'API ont fourni des méthodes surchargées avec des paramètres varargs depuis la version 1.7 de l'API.

Pour les cas où vous avez besoin de plus de 2 et que vous êtes bloqué avec SLF4J pré-1.7, utilisez simplement la concaténation de chaînes ou new Object[] { param1, param2, param3, ... }. Il devrait y en avoir suffisamment peu pour que la performance ne soit pas aussi importante.

Version courte: Oui, c'est plus rapide, avec moins de code!

La concaténation de chaînes fait beaucoup de travail sans savoir si elle est nécessaire ou non (le test traditionnel "est le débogage activé" connu de log4j), et doit être évitée si possible, car le {} permet de retarder l'appel toString () et la construction de la chaîne après qu'il a été décidé si l'événement doit être capturé ou non. En ayant le format de l'enregistreur une seule chaîne, le code devient plus propre à mon avis.

Vous pouvez fournir n'importe quel nombre d'arguments. Notez que si vous utilisez une ancienne version de sljf4j et que vous avez plus de deux arguments à {}, vous devez utiliser la new Object[]{a,b,c,d}syntaxe pour passer un tableau à la place. Voir par exemple http://slf4j.org/apidocs/org/slf4j/Logger.html#debug(java.lang.String, java.lang.Object []) .

Concernant la vitesse: Ceki a posté un repère il y a quelque temps sur l'une des listes.

Depuis, String est immuable en Java, les String gauche et droit doivent donc être copiés dans le nouveau String pour chaque paire de concaténation. Alors, mieux vaut opter pour l'espace réservé.

Une autre alternative est String.format(). Nous l'utilisons dans jcabi-log (wrapper d'utilitaire statique autour de slf4j).

Logger.debug(this, "some variable = %s", value);

C'est beaucoup plus maintenable et extensible. De plus, c'est facile à traduire.

Je pense que du point de vue de l'auteur, la raison principale est de réduire la surcharge pour la concaténation de chaînes.Je viens de lire la documentation de l'enregistreur, vous pouvez trouver les mots suivants:

/**
* <p>This form avoids superfluous string concatenation when the logger
* is disabled for the DEBUG level. However, this variant incurs the hidden
* (and relatively small) cost of creating an <code>Object[]</code> before 
  invoking the method,
* even if this logger is disabled for DEBUG. The variants taking
* {@link #debug(String, Object) one} and {@link #debug(String, Object, Object) two}
* arguments exist solely in order to avoid this hidden cost.</p>
*/
*
 * @param format    the format string
 * @param arguments a list of 3 or more arguments
 */
public void debug(String format, Object... arguments);