 |
 |
Bill, > > 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? Yes. > > 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. Yes, but compiling out is not controllable from the configuration or programmatically. I think you'll need to check isEnabledFor in the constructor, use assignment rather than initialization in that method only if the threshold is met, and (especially) do something about operator%. > > 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? I think having both alternatives is good, but others may object. -- 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