Re: [boost] [log] Release Candidate 4 released

Subject: Re: [boost] [log] Release Candidate 4 released
From: Darryl Green (darryl.green_at_[hidden])
Date: 2010-01-10 08:28:11

On Fri, 2010-01-08 at 17:14 +0300, Andrey Semashev wrote:
> I'm proud to announce that I've released the fourth candidate of 
> Boost.Log for the review.

Thanks for persisting with this. It would be great to have a truly
general purpose logging lib in boost.

> * The syslog sink backend is now supported on Windows, too. The sink no 
> longer requires native support for POSIX API for syslog, but is able to 
> send syslog packets to a remote server over UDP.

Cool.

> * Added support for scoped logging. There is now a distinct log record 
> entity, which is returned by the core as a result of filtring.

Great.

Now I have a few performance and usage issues/questions:

I haven't done more than read the docs (oh - I also checked the
performance thread on sourceforge),but if I understand correctly the
current architecture *always* evaluates all attributes so that
filtering can be applied (based on the attribute values).

In general attribute evaluation may be expensive. Presumably, in an
environment where the performance of *not logging* is important one
should be careful to use only low cost attributes. This rather reduces
the utilitity of attributes and late formatting - forcing all
(expensive) data collection to be by including the collected data in
the log message via streaming.

I wonder if some form of non-filterable, late evaluated attribute
facility should be included as well? Potentially, such a facility could
be implemented by returning at attribute value that is merely a proxy
that the formatter evaluates?

It appears from the example of adding an uptime attribute that the
attribute value is heap allocated and a shared ptr returned.
Presumably, to avoid issues with allocator performance in general and
heap contention in particular, a custom allocator should be used for
"lightweight" attributes?

Regardless the performance of all attributes provided by the library
should be documented (and/or available to the user by running some sort
of included benchmark test).

Even with the use of constant attributes, is seems filtering
performance is inherently not as good as a system which takes advantage
of the constant nature of filtering attributes by performing early
evaluation of filters and caching the result where possible.
Specifically, in the case where the logger "identity" comprised of a
set of constant attributes associated with the log, is established at
logger construction, it should be possible to determine whether the
filter (assuming the filter itself does not change) will always match
or never match at that time. Caching this result means that the
evaluation of the filter is simply the evaluation of a bool.
Potentially, this could be implemented within the proposed logging
design by making an "identity" attribute that caches internally in this
way and using it as the only attribute for loggers and filters that
require high performance when the logger is disabled.

Is this a reasonable approach to take? The main problem I see is that
in general filters are not constant and this would need some sort of
filter/attribute interaction to force reevaluation when the filter is
"newer" than the cached bool result.

The above is not contrived - the torjo logging lib provided such a
feature as the only filtering mechanism aside from a fixed
level/severity scheme. This was considered too restrictive/failed to
support some use cases. However, the exact use case it did/does support
is critical for me, so I need some way to implement it if I am to use
your library.

Regards
Darryl