Re: [boost] Some simple logging performance tests

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
> attached):
> 
>    - 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
> re-used?
> 
> 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.
> 

Thanks Caleb.

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.

Best,
John

-- 
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!