Open fh-ms opened 2 weeks ago
In Java standard JUL (java util logging) you can log lazily like this:
LOGGER.log(Level.INFO, ()->"Expensive string to compute");
Basically the lambda that computes the (potentially expensive) log string only kicks in if the log level is active.
I also highly recommend switching to Java 9 System logger facade, I filed github issues for that
This will allocate a new lambda every time though.
So while more verbose, the previously mentioned way is superior in terms of performance.
The JVM JIT is smart enough not to allocate lambdas that are the same.
Any lambda that has to capture surroundings won't be optimised by the JIT. Either way, I think it is preferable to write code in a consistent manner where you don't have to think about what the JIT might do.
And either way, even if something is technically optimisable, it doesn't mean the JIT will necessarily do so.
It's also nice to have predictable performance instead.
well, in the end its up to the microstream folks to decide anyway :D
if/else pollute the code a lot, and make it very difficult to read .. is what the problem is, especially when it is done for no real logic purpose, just logging.
To follow logger coding conventions and to optimize performance by avoiding unnecessary object allocations, we should consider adding log flag queries to logging statements, at least to those that create parameter objects.
should look like