qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++ logging - anyone heard of pantheios?
Date Thu, 03 May 2007 14:30:52 GMT
On Thu, 2007-05-03 at 08:36 +0100, Martin Ritchie wrote:
> On 03/05/07, Alan Conway <aconway@redhat.com> wrote:
> > http://pantheios.sourceforge.net/ looks interesting. Doesn't have a wide
> > selection of back-ends but appears to have a smarter front-end than
> > most, lazy formatting of arguments giving a low overhead for disabled
> > log statements without needing to wrap them in if (willBeLogged() {..}
> >
> > Anyone have experience/opinions?
> >
> > Alan.
> 
> Speaking from the java side and the efficiency of of log4j it often
> happens that we forget to put the if(isLoggingLevelEnabled()) call in
> to guard complicated log statements where a lot of string
> concatenation or processing is done before the call.
> 
> While it would be nice to have a similar logging mechanism and process
> across the implementations if pantheios has a smarter front-end that
> avoids this evaluation when logging is disabled then perhaps this is a
> good approach.

In C++ the simplest way to log is with macros which already include the
isLoggingEnabled call so that's less of an issue. However pantheios
claims to be faster even with this, since the "isLoggingEnabled" check
is only a preliminary test, you might pass it and still not log
anything. The Pantheios trick is a bunch of deferred formatter classes,
so you don't pay for formatting till you actually hit code that outputs
strings.

Unfortunately the packaging in pantheios is truly apalling. Over 50
static libs with names like "pantheios.1.bel.null.gcc40.debug.a" Ack.
They only have vc .dsps for their perf test and I gave up trying to
figure out what combination of libs was required for it to work.

I found one other interesting candidate: rlog. It has a unique approach,
in most approaches the log statement checks with the infrastructure if
it should emit a message or not. In rlog it's the other way around: log
statements register themselves with the infrastructure. When log levels
change the infrastructure visits all the log statements and sets a
function pointer to 0 or a logging function. There's a small price to
pay for registration on the first visit to a log statement but
thereafter they boil down to "if (fp != 0) { *fp(log args); }" and fp is
only non-zero if a message will get logged somewhere.

Downsides of rlog:
 - looks to me to be thread-unsafe 
 - less flexible output and formatting options than log4cxx.




Mime
View raw message