[
https://issues.apache.org/jira/browse/HADOOP-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899485#action_12899485
]
Doug Cutting commented on HADOOP-6884:
--------------------------------------
> LOG.debug("a=" + a + ", b=" + b + ", c=" + c);
The way you'd write this is:
LOG.debug("a={} b={} c={}", a, b, c);
This need not be a varargs call, but can a normal, 4-arg method call.
That said, numeric values would get boxed. In the attached patch there are
some calls that pass a single numeric value that would get boxed. If we're
concerned about the performance cost of the boxing in these cases, then we
could define methods like:
public static void debug(String format, int i) { if (log.isDebugEnabled())
log.debug(format, i); }
public static void debug(String format, long l) { if (log.isDebugEnabled())
log.debug(format, l); }
public static void debug(String format, float f) { if (log.isDebugEnabled())
log.debug(format, f); }
public static void debug(String format, double d) { if (log.isDebugEnabled())
log.debug(format, d); }
If benchmarks show this to be a significant optimization, this might argue for
creating a Hadoop-specific logging wrapper, as slf4j does not make this
optimization.
Here's a random idea: use assertions for logging! So folks could write:
assert LOG.debug(....);
where LOG.debug() would need to return 'true'.
> Add LOG.isDebugEnabled() guard for each LOG.debug("...")
> --------------------------------------------------------
>
> Key: HADOOP-6884
> URL: https://issues.apache.org/jira/browse/HADOOP-6884
> Project: Hadoop Common
> Issue Type: Improvement
> Affects Versions: 0.22.0
> Reporter: Erik Steffl
> Assignee: Erik Steffl
> Fix For: 0.22.0
>
> Attachments: HADOOP-6884-0.22-1.patch, HADOOP-6884-0.22.patch
>
>
> Each LOG.debug("...") should be executed only if LOG.isDebugEnabled() is
> true, in some cases it's expensive to construct the string that is being
> printed to log. It's much easier to always use LOG.isDebugEnabled() because
> it's easier to check (rather than in each case reason whether it's necessary
> or not).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
