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