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 <norm...@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?
