How badly is this affecting performance? I could see adding something like a GR_CHECK_LEVEL() to all the logging macros if the call to log4cpp's getPriority() is cheaper than executing the (msg) code. It probably is.
Hi Boris,
I honestly thought, up to last week, the same as you. So, this is not intended, and we'll
fix it, but sadly probably not on 3.9.
Best regards,
Marcus
On 29.07.21 07:39, Boris Marjanovic wrote:
> Hi,
>
> I've been profiling the flowgraph I've been working on and discovered that there is a lot
> of time spent in logging infrastructure even when logging levels were not enabled.
> The logging statements are not simple strings but a call to the formatting library in my
> case. I used the fmt library. So the statement looks something like :
> GR_LOG_DEBUG(this->d_logger, fmt::format("a = {} b = {}", a, b));
> (equivalent for any other formatting lib)
> So even when the logging level is at INFO, the formatting statement will evaluate to
> create a string that could/should be logged.
>
> This did not make sense to me. If the logging level is set to INFO, I would not expect the
> system to evaluate the above formatting statement. But it does due to the way macros are
> done and log4cpp manages logging statements and priority levels.
>
> I'm curious if this is desired/expected behaviour?
>
> I worked around this by defining a set of macros that check logger's logging level before
> attempting to stream a log line to the logger object.
>
> Regards
> Boris