Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-17 15:59:57

On 03/16/2010 11:29 AM, Vladimir Prus wrote:
> On Monday 15 March 2010 13:45:12 Vladimir Prus wrote:
>
> I have now measured the compile time performance. An file that outputs a string
> to std::cout and does nothing else takes 0.27 seconds to compile on my system.
> Compiling the main.cpp from 'log/example/trivial' takes 2.47. For avoidance
> of doubt, I've repeated timing several times, with no significant deviation,
> and it's naturally hot cache case.
>
> So, including Boost.Log headears appear to add 2.2 seconds to compilation time.
> This might sounds not much, but it adds up. For example, one part of KDE, named
> kdevplatform, has 562 files. So, if every one of them starts to use Boost.Log,
> that would add 1236 seconds, or 20 minutes, to the compilation time. The
> problem is that complete build of that project (which already uses KDE's logging
> mechanisms), takes 16 minutes.
>
> Hmm, maybe I did something wrong. Ah, right, trivial's main.cpp incluldes filters.hpp.
> When I try with a source file that includes only trivial.hpp, the compilation time
> is 1.67 seconds, the overhead being 1.4 per file and estimated overhead on my
> project being 786 seconds or 13 minutes. Still, compared to 16 minutes it takes
> to compile "business code", 13 minutes overhead seems unacceptable. Does anybody
> sees any flaw in my methodology?
>
> Unless I'm wrong, I recommend that trivial logging be redesigned to cut down on
> includes necessary. On the extreme end, printf-style wrappers can reduce compile
> time overhead to nearly zero. It probably would be possible to abstract things
> away so that
>
> 	BOOST_LOG_TRIVIAL(...)
>
> essentially returns std::ostream, without exposing the real types to the user code.

Thanks for the figures.

Right now I cannot comment on what is the reason on such performance. I 
don't think it's unacceptable, but I would surely be willing to minimize 
it as much as possible (without much impact on the user's interface, if 
possible).

Quick analysis shows that the amount of code brought in by trivial.hpp 
is rather big, and this might be one source of the problem. For 
instance, it brings in a great deal of Boost.DateTime (through 
Boost.Thread) and Boost.MPL and Boost.TypeTraits (partially, through 
Boost.Parameter). I guess, I'll have to either reimplement some parts of 
these libraries or use hacks to hide them completely within Boost.Log 
binary to speed up the compilation.

BTW, have you tried if precompiled headers help?