Re: [boost] Boost.Log: Any Comments? (Was: [log] Permission to merge to trunk)

Subject: Re: [boost] Boost.Log: Any Comments? (Was: [log] Permission to merge to trunk)
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-03-29 07:58:42

Then I will write a brief summary of my point of view.

First, I think boost.log is by far the best logging system I've used,
simply because it don't impose
anything on the way I want the logging to be setup.

I have one project in development using it (I will use it soon in another
project which is open source).
It's a game, multi-threaded (using tbb and boost), multi-process
(client/server even with one computer solo game).
It's composed of a lot of dlls, one hosting basic system code, like logging.
Note that so far I only compiled both my projects and boost.log on Visual
Studio 2010 and 2012 (my project only compile with 2012).
I intend to try with clang and gcc but will not be able to work on this for
several months.

In this project I simplified the use of logs a lot, so I don't really use
channels and other filtering features.
However, I do use heavy/complex formatting and multiple sinks (vs console,
console, files) with different formatting.
In my setup I have only one cpp file using boost.log, which have a logging
function called by other external code ( a bit like the setup I've pushed
into cpp-netlib:
https://github.com/cpp-netlib/cpp-netlib/tree/master/logging/src ).
The main reason was that when you have multiple dlls, you should link them
all to one boost.log dll.
I compile all boost as static libraries and didn't want to make an
exception so I just used boost.log in one
only dll which is used by other dlls. As I don't need boost.log in my
interfaces, I can do that, but others
would be forced to link all dlls to boost.log dlls if they use boost.log in
their interfaces OR if they use it in
headers.
I'm explaining all that so that you understand that I'm not in a common
setup, I have only one cpp using
boost.log and configuring logging exactly it the way I want.

This mean that I have no idea on the compilation performance of boost.log
as I compile it only once for all the project.

On the run-time performance, yesterday I removed totally the logging code
and run the game again.
I didn't see a difference. I'm using synced sinks for now, I don't think
the asyncs would help (other than delaying the logs in the console).
However, I didn't measure anything AND I am too early in the development of
this game to have reached any visible bottleneck.
Which means that apparently boost.log don't seem to impact my game's
performance, but it's too early to be totally sure.
I think there will not be more problem than any other logging library on
the performance side, and if there is, it's really easy to tweak it.
Note that in my context, logs are coming from a lot of different threads
and simultaneously, so it don't seem to be a problem for boost.log.

Configuring the logging system so that I get exactly what I want is not
always easy/obvious, both because there is a lot of options and
because of some syntax tricks (boost.parameter usage example) which help
once you know them but are obscure when you don't.
Obviously, reading most of the documentation clarify things a lot, but I
fear that people not taking logging seriously
and just wanting a log file out will not read more than a few page.
This is, I guess, expected so it's not a real problem. Boost.Log seem to
allow all setups I've seen so far in different projects
in widely different companies with widely different kind of software which
make me wish boost.log was part of the c++ standard.
I also wish the syntax to setup the configuration wasn't so verbose, but I
don't see any way to reduce it, and it's easy to isolate.

Most of the issues I had were in v1 but they were not critical. Some were
actually specific to the VC compilers and not specific to boost.log.
I switched to V2 recently and seen no change other than the one I pointed
in the previous thread (which are not big problems).

About the core being a singleton instead of function interface, I think
that's the right choice as I've been confronted to the case
where terminate() is called and I need to log something before quitting. I
don't remember all the details but the problem I had
was that there were chances that the boost.log core was deleted at the
point I wanted to log before exiting. To solve this,
just taking a shared pointer to the core at the being in a system that I
guaranteed to be alive until the end solved the problem.
I think that's the kind of situation Andrey was talking about to justify
the core to be an object instead of a set of functions.

I used boost log in some basic test projects and the availability of the
trivial logging was really helpful.

One thing I'd like to see in the future is to have some helper code to
setup multi-process logging.
Basically, I think (using asio) a log_client sink and a log_server logger
would be helpful.
The first one would automatically convert a log_record to something that
can be sent (in a cross-platform way) to the network
and assume it will be received by an application keeping a log_server
object which would receive this log_record, then
push it in it's own boost.log core.
Users can already do this themselves, but I think if it would be helpful to
have such tools in a (certainly not soon) future ready in the
library distribution, like the other helper functions provided.
As it would involve boost.asio (in my case I use another network library)
AND a specific log_record serialization (maybe I prefer a specific binary
format),
I think providing this solution would be helpful, like most boost.log
helpers, but also a basic example to setup more specific or complex setup
for multi-process logging.
The helper functions helped me sometime understand how some setups were
done.
But really I don't assume such feature would be provided in the near
future, so that's just a suggestion.

I didn't check the binary size cost, with this project I don't really care.
The current size of the binary using boost.log is 690kb and it include a
lot of code.

I think I've said it all, I can't wait for boost.log to be finally in a
boost release!

Joel Lamotte