you could certainly use the
you could certainly use the *template* to drive the cost significantly downhaving too many if-else just for logging checking is kinda counter productive
View ArticleIf the value for the logging
If the value for the logging is not the result of a method call you could get rid of the logger.isDebugEnabled() by logger.debug("failed because of foo: {} and bar: {}", foo, bar); The...
View ArticleYes, the template's better if
Yes, the template's better if your API has it, and you can use it (not every value has a properly formatted toString()). Otherwise, if-else is way better from a numbers standpoint, though I agree it...
View ArticleThere's an example of that in
There's an example of that in my test class, and I measured it. It is indeed just as fast as if-then.I just mentioned it in passing in the blog post; probably should have given it more play and shown a...
View ArticleIt's not only an
It's not only an execution-time related problem - I saw memory (OOME) problems related to 'debug' statements without 'ifs' around them under heavy load - garbage collector was not able to release...
View ArticleThat's a great point, thanks.
That's a great point, thanks. Caliper had to run the "concatenation" test multiple times because it kept getting interrupted by GC.
View Articlelogging lib without template?
logging lib without template? this is pretty unusable ... even the vanilla JUL has the template, and modern IDEs should be able to help u refactor the string concatenation to templates automaticallynot...
View ArticleI use the below approach.
I use the below approach. Code becomes so clean and neat. No string appending unless the level is actually enabled.Extend the Logger class.Write overloaded methods debug(Object... args) warn(Object......
View Article
