On 30.12.2014 17:07, Claes Redestad wrote:
Hi Jaroslav, thanks for looking at this!
On 2014-12-30 14:43, Jaroslav Bachorik wrote:
While it's good to see the dead code gone I would prefer keeping the
logging code just commented out - the logging code could be useful
when investigating any future failures.
Do you mean all of it, or just the utility methods? I'm in the habit of
not checking in commented out code (due to potential for bit rot etc)
and instead rely on recreating from VCS history, but I have no strong
preference.
As a matter of fact I don't like the commented out code much either.
How about leaving the non-trivial dumpAll/dump_entry_fixed-methods
(which use the DEBUG flag but not the log/logln methods), but removing
all log/logln calls?
The affected files are pretty stable so we could remove *all* the
logging related methods. When a necessity arises to have a configurable
logging we would just need to re-introduce it properly. This got me
thinking - a comment warning about the possible performance issues when
adding logging could be added as a courtesy to the later maintainers.
-JB-
Converting to j.u.l. wouldn't probably completely remove the
unnecessary allocation (due to object arrays for varargs) unless you
guard each log call for the required logging level.
Guards or simply using only single-parameter log methods in j.u.l is
generally doable workarounds when performance matters so much that even
the varargs allocation matters. I can only hope
https://bugs.openjdk.java.net/browse/JDK-8013269 or similar will deal
with removing that overhead generally, though.
/Claes
-JB-
