Hi K-T -

See my responses below. . .

Regards,
Bill

On May 13, 2014, at 6:40 AM, Kian-Tat Lim <[log in to unmask]> wrote:

> Bill,
> 
> 	auto_ptr is a bit much; more typical is just to construct a
> local variable that will go out of scope at the end of the block:
> 
> {
>    LOG_CTX context("demo");
>    // ...
> }
Fair enough. I've updated the demo code in qserv and the Trac documentation to use the above pattern, which indeed works just fine.

> 
> 	It might be nice to have context objects for MDC as well.
Are you envisioning distinct objects solely for MDC. That is, one MDC context object per key/value pair?

> 
> 	I'm a little worried about the copies in the ProtoLogFormatter
> constructor.  Have you timed this?
This very well could be an issue. With the threshold set such that logging messages do not print, calls to the present ProtoLog API can take 5 to 13 microseconds (or longer) depending on the amount of formatting. This is dramatically longer than the few nanoseconds of the previous implementation that used varargs and snprintf.

At the same time, I have shown that by mapping macros such as LOG_INFO() or LOG_DEBUG() to the new macro LOG_NO_OP() (see the latest code) this overhead can be reduced to about 20 nanoseconds in a production environment. I elaborate on this a bit in the latest Trac documentation.

Perhaps I can speed things up by avoiding unnecessary copying. I'll look into this.

> 
> 	And does supporting operator% mean you *can't* support snprintf?
> Or would that require a whole parallel set of macros?
It is certainly possible to provide a varargs/snprintf interface using separate macros and/or functions. I toyed around a bit with the goal of unifying this interface style with that of boost::format, but an elegant solution wasn't immediately apparent to me. Do you believe having both of these interfaces available is desirable? Or should there be a policy that embraces one over the other in which case we would not gain from complicating the logging API? Perhaps the timing measurements reported above make the varargs/snprintf option more attractive. 
> 
> -- 
> Kian-Tat Lim, LSST Data Management, [log in to unmask]

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1