boostorg / boostorg/log

Performance issue: Boost.Log does a huge work when filtering records

Open
#202 4 comments 1 reaction 0 assignees View on GitHub
Dominant language
C++
Stars
211
Forks
113
PR merge metrics
No merged PRs in 30d

Description

I worked with Boost.Log library and encountered a huge performance impact in case when all content passed to the logger supposed to be filtered.
I reduced the logger to the simplest one with a console backend and the result remained the same.

Here is the sample code:
```
#include
#include
#include
#include
#include
#include
#include
#include
#include

enum severity_level
{
critical,
info,
trace
};

BOOST_LOG_ATTRIBUTE_KEYWORD(severity_level_kw, "Severity", severity_level)

using backend_type = boost::log::sinks::synchronous_sink>;

bool filter_impl(severity_level lvl) { return lvl < trace; }
bool filter(const boost::log::value_ref & lvl) {
return filter_impl(*lvl);
}

void logging_function() {
auto sink = boost::make_shared();
sink->set_filter(boost::phoenix::bind(&filter, severity_level_kw.or_none()));
sink->locked_backend()->add_stream(boost::shared_ptr(&std::cout, boost::null_deleter{}));
boost::log::core::get()->add_sink(std::move(sink));

boost::log::sources::severity_logger slg;
for(int i = 0; i < 100000000; ++i) {
// I expect this line only applies the filter and does nothing else since trace-messages supposed to be filtered
BOOST_LOG_SEV(slg, trace) << "Trace message: " << i;
}
}

int main()
{
logging_function();
return 0;
}
```
This simple program works for ~14 seconds.
But if I change the loop like this:
```
for(int i = 0; i < 100000000; ++i) {
if(filter_impl(trace))
std::cout << "Debug message: " << i << "\n";
}
```
the program completes instantly as it supposed to. And it's what I expect the log library should do.

I profiled the program with dotTrace and here is the result

![image](https://user-images.githubusercontent.com/4507636/211599164-acf0b592-d8da-410a-b6c2-2bcd41ffebe7.png)

As you can see `filter` function takes only 95ms and the rest time goes to another stuff including memory allocations which I wouldn't expect to see.

This problem makes Boost.Log unusable in cases when performance is a priority.

As a hot-fix one can filter records manually by introducing a special macro, for example.

But is it worth expecting this issue will be fixed?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.