From: John Torjo (john.lists_at_[hidden])
Date: 2005-11-16 10:16:29
> I've also profiled this code, and found some not-too-suprising results (also
> - When the logger is enabled, the bulk of this program's time is spent
> in boost:logging::enabled_logger::~enabled_logger, which is calling
> write_msg with the result of std::ostringstream::str.
> - When the logger is disabled, much of the time is spent in
> ~enabled_logger as well as the is_enabled check
> Overall, the performance of the Boost.Log library when output is enabled is
> almost an order of magnitude slower than just writing the same data to a
> standard iostream. I believe the overhead of the enabled_logger design
> (object creation, heap allocation of an ostringstream every time a message
> is logged) might bear some re-examination. Is the enabled_logger object
Yes, heap allocation does consume a lot of time.
> really necessary? Can the ostringstream be created on the caller's stack
> instead of the heap (e.g. by re-writing the BOOST_LOG macro) or perhaps
> I believe that the syntax of the logging macros (e.g. BOOST_LOG (x) << ...),
> while clever, contributes to the relatively poor performance of the library
> when compared to bare iostreams. I would suggest that by enclosing the
> entire logging statement in the macro invocation (e.g. BOOST_LOG(x, ...) ),
> a more optimal, feature-rich implementation is be possible. It becomes
> exceedingly simple to implement compile-time removal of logging calls with
> the "enclosed" macro-based interface, obviating the need for the
> is_compile_time complexities in the current code. Additionally, messages
> might be logged with __FILE__ and __LINE__ information automatically (if so
Yes, I'll allow for __FILE__, __LINE__.
> desired). I'm sure there are other benefits (and weaknesses) that I'm
> overlooking as well.
I will definitely use this as a start, when implementing the new version
of the logging lib.
A lot of optimizations can be done, especially on the macro area.
-- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk