[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Logging GR 3.9

From: Jeff Long
Subject: Re: Logging GR 3.9
Date: Thu, 5 Aug 2021 06:15:05 -0400

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.

On Wed, Aug 4, 2021 at 2:28 PM Marcus Müller <mmueller@gnuradio.org> wrote:
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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]