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?