News for hackers. Stuff that matters.
Re:Logging vs. instrumentation by tonyarkles on Monday February 08, 2016 @11:26AM (#11058999)
I don't know why you're getting downvoted, because in my mind you're right in some circumstances. More than once, I've found logging-related performance issues (i.e. logging is near the top of a profiling-driven performance optimization task).

One immediate example that comes to mind was code that had a bunch of logging statements like log.debug(boost::format("%d %x etc", param, param)). Normally the code would run with debug logging turned off, but there's a pretty brutal problem there! The formatted string is always going to be processed, which the logger will immediately discard. Turns out one of these formatted strings actually took a fair bit of processing to generate and was hurting the system.

Re:Logging vs. instrumentation by kedean on Monday February 08, 2016 @04:18PM (#11060956)
That's a solved problem. Your logger should be capable of formatting on it's own, and take the arguments to the format string as variadic arguments. This is how Java's ubiquitous SLF4J interface is defined. If the log level isn't low enough, then the arguments are tossed but never composited.
Re:Logging vs. instrumentation by azth on Monday February 08, 2016 @05:17PM (#11061268)
And it's even better with languages with macros, like Rust, Scala, even C++. There won't be any function call to begin with if the corresponding logging level is not enabled, only a branch.
Re:Logging vs. instrumentation by tonyarkles on Tuesday February 09, 2016 @08:34PM (#11070213)
I replaced it with a macro!