Boost logo

Boost Users :

Subject: Re: [Boost-users] [log] cost of record instantiation
From: Oskar Nordquist (oskar.nordquist_at_[hidden])
Date: 2010-08-31 03:30:58


2010/8/30 Matthias Vallentin <vallentin_at_[hidden]>:
> I am trying to understand the cost of log record instantiation. Say I
> have a global severity logger with several levels, of which the debug
> level produces a lot of output and record creation is expensive. Because
> the overhead should only incur when actually logging in debug mode, I
> would like to know how costly the level check is. That is, in the
> following code
>    // The custom logger class here accommodates multiple severity
>    // loggers for different facilities.
>    #define LOG(level, facility)                                    \
>        BOOST_LOG_SEV(global::logger->get(facility), level)
>    LOG(debug, core) << ... some expensive construction
> would the stream expression be instantiated regardless of the logging
> level, yet simple be discarded when being in level lower than debug? (I
> am asking because I recall they are not streamed in a lazy fashion.) If
> this is the case, preventing the construction of the stream expression
> would need a different logging mechanism, e.g.,
>    /// Expensive logging when in Debug mode.
>    #ifdef DEBUG
>    #define LOGD(facility)                                          \
>        LOG(log::debug, facility)
>    #endif
>    // Not being compiled.
>    LOGD(core) << ... some expensive constrution
> However, this design does not have a uniform approach to logging, which
> makes it less attractive.
> Any thoughts?

I have just started using Boost.Log myself, but I am fairly certain
that *because* it is not using lazy streaming, you don't pay the cost
of the stream instantiation [1].

The BOOST_LOG() and BOOST_LOG_SEV() macros actually expands to a for
loop checking the filters, before any streaming construction takes

By the way, you will have better luck getting attention from the
author over at the Sourceforge forums:




Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at