Logger slf4j advantages of formatting with {} instead of string concatenation

Question

Is there any advantage of using {} instead of string concatenation?

An example from slf4j

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

instead of

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

I think it's about speed optimization because parameters evaluation (and string concatenation) could be avoided in runtime depending on a config file. But only two parameters are possible, then sometimes there is no other choice than string concatenation. Needing views on this issue.

https://www.slf4j.org/faq.html#logging_performance – Grigory Kislin Jun 08 '22 at 10:20 — Grigory Kislin, Jun 08 '22 at 10:20

score 90 · Accepted Answer · edited May 20 '14 at 20:17

90

It is about string concatenation performance. It's potentially significant if your have dense logging statements.

(Prior to SLF4J 1.7) But only two parameters are possible

Because the vast majority of logging statements have 2 or fewer parameters, so SLF4J API up to version 1.6 covers (only) the majority of use cases. The API designers have provided overloaded methods with varargs parameters since API version 1.7.

For those cases where you need more than 2 and you're stuck with pre-1.7 SLF4J, then just use either string concatenation or new Object[] { param1, param2, param3, ... }. There should be few enough of them that the performance is not as important.

edited May 20 '14 at 20:17

Hendy Irawan

20,498
11
103
114

answered May 11 '12 at 16:49

skaffman

398,947
96
818
769

3

Unused string concatenation (i.e. debugging statements) should be avoided. Do use either the (overly verbose but efficient) log-level check or the (slimmer, but perhaps minor overhead) object array parameter. (I'd prefer the latter, all things being equal.) It's hard to say that the string concat's won't be important/won't impact performance. The object array creation could in theory be inlined and optimized away and "really" not make a difference (vs. wishful thinking). (It's not premature optimization, it's simply a matter of doing something right/better the first time.) – michael Feb 18 '13 at 21:56
1

why overloaded modifications are not done for System.out.println() to follow similar to slf4j's logger,so that it avoids string concatenation? – a3.14_Infinity Nov 26 '14 at 10:46

score 62 · Answer 2 · edited Sep 18 '19 at 17:58

62

Short version: Yes it is faster, with less code!

String concatenation does a lot of work without knowing if it is needed or not (the traditional "is debugging enabled" test known from log4j), and should be avoided if possible, as the {} allows delaying the toString() call and string construction to after it has been decided if the event needs capturing or not. By having the logger format a single string the code becomes cleaner in my opinion.

You can provide any number of arguments. Note that if you use an old version of sljf4j and you have more than two arguments to {}, you must use the new Object[]{a,b,c,d} syntax to pass an array instead. See e.g. http://slf4j.org/apidocs/org/slf4j/Logger.html#debug(java.lang.String, java.lang.Object[]).

Regarding the speed: Ceki posted a benchmark a while back on one of the lists.

edited Sep 18 '19 at 17:58

Naman

27,789
26
218
353

answered May 15 '12 at 07:52

Thorbjørn Ravn Andersen

73,784
33
194
347

8

note: the latest javadoc shows the newer var-arg syntax, `debug(String format, Object... arguments)`. See http://slf4j.org/faq.html#logging_performance – michael Feb 18 '13 at 21:58
Upvoted because of mention of .toString() evaluation in addition to concatenation performance. This is something that happens inside the logger and logger can decide whether it's necessary to invoke that method. It does not if the logging level bar is not met. – Chetan Narsude Mar 31 '16 at 00:29

score 8 · Answer 3 · answered Apr 25 '18 at 16:12

8

Since, String is immutable in Java, so the left and right String have to be copied into the new String for every pair of concatenation. So, better go for the placeholder.

answered Apr 25 '18 at 16:12

Rabin Pantha

941
9
19

6

This is correct if there is a single pair, but generally incorrect, as the compiler turns concatenation into string-builder calls, resulting in much faster code that doesn't do as much allocation. – cdeszaq Jan 28 '19 at 19:18

score 3 · Answer 4 · answered Oct 05 '12 at 06:36

3

Another alternative is String.format(). We are using it in jcabi-log (static utility wrapper around slf4j).

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

It's much more maintainable and extendable. Besides, it's easy to translate.

answered Oct 05 '12 at 06:36

yegor256

102,010
123
446
597

4

I do not think it's more maintainable. if the type of `value` changes, you have to go back and change the logging statement as well. Something that IDEs will not help you with. Loggers should assist with debugging and not come into the way of it. :-) – Chetan Narsude Mar 31 '16 at 00:32
3

@ChetanNarsude IntelliJ 2016 at least tells me when the format string does not fit the formatting arguments. For example: `String.format("%d", "Test")` produces the IntelliJ warning `Argument type 'String' does not match the type of the format specifier '%d'.`. Though, I'm not sure it would still be able to provide this intelligent response when working with the above solution. – crush May 28 '16 at 19:39
what is the speed of this? – Thorbjørn Ravn Andersen Apr 20 '17 at 08:39
@ThorbjørnRavnAndersen it's pretty primitive inside, but of course it's slower than a static logger – yegor256 Apr 20 '17 at 15:19
2

Wrapping slf4j? doesn't that defeat the purpose of using slf4j? Also, I have seen many people misuse String.format such that the string gets formatted before the log level is evaluated, like: logger.info(String.format("hello %s", username)). – Juan Bustamante Apr 24 '18 at 20:26
@ChetanNarsude That's completely incorrect. You can use `%s` for everything. – Martin F Apr 28 '21 at 14:38
@crush It's kind of late but just wanted to stand corrected on what I meant. IDEs will tell you to correct it, but will not correct it - change it from "%d" to "%s". That is something is not even needed with the '{}' syntax. – Chetan Narsude Aug 16 '21 at 01:34
@MartinF Here is an example that you cannot use `%s` for everything. `String.format("%s", new Object[1, 2.0, "3"])` returns `[Ljava.lang.Object;@cafebabe` while `logger.info("{}", new Object[1, 2.0, "3"])` would print `[1, 2.0, 3]`! – Chetan Narsude Aug 24 '21 at 07:19

score 2 · Answer 5 · answered Sep 12 '18 at 21:59

I think from the author's point of view, the main reason is to reduce the overhead for string concatenation.I just read the logger's documentation, you could find following words:

/**
* <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);

score 1 · Answer 6 · answered Mar 28 '22 at 12:38

Concatenation is expensive, so you want it to happen only when needed. By using {}, slf4j performs the concatenation only if the trace is needed. In production, you may configure the log level to INFO, thus ignoring all debug traces.

A trace like this will concatenate the string even if the trace will be ignored, which is a waste of time :

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

A trace like this will be ignored at no cost :

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

If you have a lot of debug traces that you ignore in production, using {} is definitely better as it has no impact on performance.

score 0 · Answer 7 · answered Jan 26 '22 at 13:58

Compliant logging is highly important for application development, as it affects performance.

The mentioned non-compliant logging is resulting with redundant toString() method invocation on each call, and is resulting with redundant temporary memory allocation and CPU processing, as can be seen at example high scale test execution, where we can take a look on redundant allocated temporary memory: Memory

Look on method profiling:

Note: I am the author of this blog post, Logging impact on application performance.

Logger slf4j advantages of formatting with {} instead of string concatenation

7 Answers7

Linked

Related