You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Dan Bush <da...@gmail.com> on 2005/08/29 21:14:33 UTC
Possible API Performance and Usability Enhancement
I have been recompiling log4j locally for years now to overload the
logging signature so I can take advantage of java.text.MessageFormat
and embed the isXXXEnabled check. Below I have detailed out what I am
doing but, I would like to know if it is something that could be
incorporated into the framework and if so how do I go about submitting
it?
Suppose you have this complex customer information object. Through
configuring the logging level, you can avoid the overhead to the
filing system but, it seams silly to still have to eat the toString
overhead unless you wrap isXXXEnabled() around it:
CustomerInformation ci = new CustomerInformation();
USAGE 0:
============================
logger.debug(ci);
This is ok but even when the logging level is adjusted to avoid the
logging, ci is still toString() ed which translates to unnecessary
string tomfoolery. Depending the object and the toString()
implementation this can get far uglier. Image you are using a dynamic
bean style driven toString() utility routine or the object is a
composit ...
USAGE 1:
============================
if (logger.isDebugEnabled()) {
logger.debug(ci);
}
This avoids the toString() overhead(for DEBUG) overhead but, it messy
when used at scale.
USAGE 2: (SUGGESTED EXTENDED API)
============================
logger.debug("ci:[{0}]", ci);
Here I am using a wrapper method which does the isDebugEnabled()
within and then java.text.MessageFormat.format(String pattern,
Object[] arguments) if necessary. Of course I over load the signature
for convenience as well. For example debug:
debug(String message, Object [])
debug(String message, Object obj0)
debug(String message, Object obj0, Object obj1)
debug(String message, Object obj0, Object obj1, Object obj2)
Throwable ...
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Possible API Performance and Usability Enhancement
Posted by Curt Arnold <ca...@apache.org>.
On Aug 29, 2005, at 2:52 PM, Dan Bush wrote:
> Excellent.
>
> On 8/29/05, Ceki Gülcü <ce...@qos.ch> wrote:
>
>>
>> Dan.
>>
>> Are you aware of SLF4J API which already incorporates a similar
>> approach?
>>
The same pattern is also in the CVS HEAD. However, I think there is
a better approach. This topic was discussed on the slf4j-dev mailing
list earlier in the thread "NLS in Logger" starting in 2005-08-05
(http://marc.theaimsgroup.com/?l=slf4j-dev&m=112327572703543&w=2).
The current approach in the CVS HEAD, slf4j and nlog4j implement a
subset of the behavior of java.text.MessageFormat. I have not had
time to confirm whether the subset implementation actually offers any
performance advantage over java.text.MessageFormat. However,
java.text.MessageFormat is just one of the potential formatters, like
the JDK 1.5's java.util.Formatter, that could be used.
In addition, if you review the slf4j-dev mailing list, you will see a
some discussion about what combinations of parameters should be
supported in the overloaded logging methods. For example, http://
marc.theaimsgroup.com/?l=slf4j-dev&m=112313497512402&w=2. The
decision of what parameters are supported is a compromise between
performance and complexity and what is a good balance for one
developer may be less than optimal for another.
My current suspicion is that an approach of using an static class
would result in performance close if not identical to the approach in
CVS HEAD on a modern JIT, would not lock developers to one formatter
and would allow the developer to use an alternative implementation if
desired.
The approach is basically something like:
public final class LogFormat {
private LogFormat() {}
public static debug(final Logger logger, final String format,
final Object param1) {
if (logger.isDebugEnabled()) {
logger.debug(java.text.MessageFormat.format(format.
param1));
}
}
//
// many more combinations of parameters to follow
//
}
In use, it would look something like:
LogFormat.debug(logger, "ci:[{0}]", ci);
I'd assume that modern JITs would effectively inline the LogFormat code.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Possible API Performance and Usability Enhancement
Posted by Dan Bush <da...@gmail.com>.
Excellent.
On 8/29/05, Ceki Gülcü <ce...@qos.ch> wrote:
>
> Dan.
>
> Are you aware of SLF4J API which already incorporates a similar approach?
>
> See for example the Logger class:
>
> http://www.slf4j.org/api/org/slf4j/Logger.html
>
> At 09:14 PM 8/29/2005, Dan Bush wrote:
> [cut]
> >USAGE 2: (SUGGESTED EXTENDED API)
> > ============================
> >
> >logger.debug("ci:[{0}]", ci);
> >
> >Here I am using a wrapper method which does the isDebugEnabled()
> >within and then java.text.MessageFormat.format(String pattern,
> >Object[] arguments) if necessary. Of course I over load the signature
> >for convenience as well. For example debug:
> >
> >debug(String message, Object [])
> >debug(String message, Object obj0)
> >debug(String message, Object obj0, Object obj1)
> >debug(String message, Object obj0, Object obj1, Object obj2)
> >
> >Throwable ...
> >
> >- Dan
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Possible API Performance and Usability Enhancement
Posted by Ceki Gülcü <ce...@qos.ch>.
Dan.
Are you aware of SLF4J API which already incorporates a similar approach?
See for example the Logger class:
http://www.slf4j.org/api/org/slf4j/Logger.html
At 09:14 PM 8/29/2005, Dan Bush wrote:
[cut]
>USAGE 2: (SUGGESTED EXTENDED API)
> ============================
>
>logger.debug("ci:[{0}]", ci);
>
>Here I am using a wrapper method which does the isDebugEnabled()
>within and then java.text.MessageFormat.format(String pattern,
>Object[] arguments) if necessary. Of course I over load the signature
>for convenience as well. For example debug:
>
>debug(String message, Object [])
>debug(String message, Object obj0)
>debug(String message, Object obj0, Object obj1)
>debug(String message, Object obj0, Object obj1, Object obj2)
>
>Throwable ...
>
>- Dan
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org