Re: design rationale

[Robert Middleton <os...@gmail.com>]

Note: I wasn't involved with the design of this at all, but some thoughts:

Likely the reason this was done is because that's how log4j worked -
the classes that you see in log4cxx map closely to log4j(1) classes.
One of the problems involved with storing the level directly in the
logger would be actually traversing the log tree to find the correct
level to set would be prone to error, especially if you're changing
the levels at runtime.  It's simpler and less likely to cause errors
if you simply check whenever you log a message.

With performance as well, the thing to recognize about logging(and
really outputting data from an application in general) is that writing
is sloooooooow.  For instance, here's a simple C program you can try:

#include <stdio.h>

int main( int argc, char** argv ){
        for( int x = 0; x < 1000000; x++ ){
                printf( "hi this is a line\n" );
        }
}

When running on my system, this takes ~2.2 seconds to run, printing to
stdout.  If I instead output the data to /dev/null, it takes between
.02 and .05 seconds.  Sending it to a file about doubles this time to
about .04 - .08 seconds, so still slower than discarding the data but
several times faster than writing to stdout.

Taking all of this together, it's very likely that storing the log
level directly in the logger wouldn't have any appreciable difference
in efficiency, unless you're trying to log thousands of statements per
second.  There's probably some way this could be improved, but unless
you actually profile and can point to a specific spot in the code
where a lot of time is being spent, it's probably not worth it to
change.

-Robert Middleton

On Tue, Mar 31, 2020 at 3:04 PM Norman Goldstein <no...@telus.net> wrote:
>
> I very much appreciate the great description of how to use log4cxx. My
> question is about a design choice that affects performance (paragraph 2
> in https://logging.apache.org/log4cxx/latest_stable/usage.html ).  A
> hierarchical approach for logging levels makes sense. However, each
> run-time check of the level involves a walk of the logger hierarchy.
> Why not do this walk when assigning levels, so that the walk does not
> need to be done at each call to log i.e. each logger stores its logging
> level, directly?

Re: design rationale

[Ralph Goers <ra...@dslextreme.com>]

I would suggest that if a change were to be made it should follow the design Log4j 2 uses and separate the configuration from the Logger instances. The hierarchy in the configuration is likely to be much smaller than it is in the Logger instances.

Ralph

> On Apr 1, 2020, at 10:06 AM, Robert Middleton <os...@gmail.com> wrote:
> 
> Note: I wasn't involved with the design of this at all, but some thoughts:
> 
> Likely the reason this was done is because that's how log4j worked -
> the classes that you see in log4cxx map closely to log4j(1) classes.
> One of the problems involved with storing the level directly in the
> logger would be actually traversing the log tree to find the correct
> level to set would be prone to error, especially if you're changing
> the levels at runtime.  It's simpler and less likely to cause errors
> if you simply check whenever you log a message.
> 
> With performance as well, the thing to recognize about logging(and
> really outputting data from an application in general) is that writing
> is sloooooooow.  For instance, here's a simple C program you can try:
> 
> #include <stdio.h>
> 
> int main( int argc, char** argv ){
>        for( int x = 0; x < 1000000; x++ ){
>                printf( "hi this is a line\n" );
>        }
> }
> 
> When running on my system, this takes ~2.2 seconds to run, printing to
> stdout.  If I instead output the data to /dev/null, it takes between
> .02 and .05 seconds.  Sending it to a file about doubles this time to
> about .04 - .08 seconds, so still slower than discarding the data but
> several times faster than writing to stdout.
> 
> Taking all of this together, it's very likely that storing the log
> level directly in the logger wouldn't have any appreciable difference
> in efficiency, unless you're trying to log thousands of statements per
> second.  There's probably some way this could be improved, but unless
> you actually profile and can point to a specific spot in the code
> where a lot of time is being spent, it's probably not worth it to
> change.
> 
> -Robert Middleton
> 
> On Tue, Mar 31, 2020 at 3:04 PM Norman Goldstein <no...@telus.net> wrote:
>> 
>> I very much appreciate the great description of how to use log4cxx. My
>> question is about a design choice that affects performance (paragraph 2
>> in https://logging.apache.org/log4cxx/latest_stable/usage.html ).  A
>> hierarchical approach for logging levels makes sense. However, each
>> run-time check of the level involves a walk of the logger hierarchy.
>> Why not do this walk when assigning levels, so that the walk does not
>> need to be done at each call to log i.e. each logger stores its logging
>> level, directly?
>