[pletnes]

Interesting. How do you enable «trace-level» logging without writing «log.trace(...)» absolutely everywhere in your code? And what about performance?

For context, I mostly program in python. I could imagine compile-time loglevel settings could address the performance, though.

[timeattack]

I code mostly in Go. And yes, I'm writing `log.Tracef` everywhere.

Might seem tedious, but in fact it's easily automated using snippets in the editor.

Also when I'm inserting trace statements during development it provides a great help since it's much easier to debug logic.

Regarding performance: I don't think that we need to worry about log performance. Most applications we have this days are not performance-bound to the logging. And all it takes to disable particular log level is single `if` in the code. Or a build flag in more extreme cases.

[stickfigure]

At least in Javaland, the "should I log" condition test for most logging libraries takes nanoseconds. Unless you're in an extremely tight loop, performance is fine.

[benschulz]

If it was absolutely necessary you could even have the JIT remove the code and then de-optimize when you enable tracing[1]. That would solve the tight-loop issue..

[1]: https://community.oracle.com/blogs/forax/2011/12/17/jsr-292-...

[pkolaczk]

Correct, in simple cases it can do it, but you need to be very careful with computing the arguments for the logging call. Java has no lazy evaluation of args nor macros, so if you accidentally concat strings there or do something expensive, it is likely JVM won't optimize these out. That's why typically you want to guard your logging calls on the hot path with an if condition.