Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-16 04:29:27

On Monday 15 March 2010 13:45:12 Vladimir Prus wrote:

> * I have used the attached script to measure code size impact. The script basically
> creates a test file with a single function calling BOOST_LOG_TRIVIAL and measures
> the size of that function depending on the number of calls. I've got 139 bytes per
> call for 'g++ -Os' and 174 per call for 'g++ -O3', which seems nice. This is function
> code only. When counting file size I get 324 and 514 respectively. For reference, kDebug
> gives 136 and 328 of file_size_bytes per call. I guess these results are OK.

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,
Volodya