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
