RE: efficiencies of getLogger()

[da...@l-3com.com]

Sorry for the late reply

I had to think about it for a bit, but I finally remembered.

We had a single class instance, which could represent a variety of
things.  They were assembled based on a data file. (Think of lego
bricks, where the bricks are C++ classes)

Each class when created, had a fully qualified textual name to describe
what they are representing.  Due to the scope and great number of things
being created, we wanted to log based on the FQN.  For instance:

Class Name: "Foo"
FQN1:  "A.B.C"
FQN2:  "D.E.F"

Class Foo, could be assembled to represent A.B.C or D.E.F.  You could
only create A.B.C once, or 100 times.  So, we couldn't create a static
logger, but we could make a getLogger() call which would cache the
logger once it was created.

I seem to recall reading that there was a caching functionality within
getLogger() itself, but by simply putting in code similar to:


std::map<std::string, LoggerPtr> loggerCache;

LoggerPtr getLogger2(std::string name)
{
	if (loggerCache.find(name) != loggerCache.end())
	{
		return loggerCache[name];
	}
	else
	{
		LoggerPtr lp = getLogger(name);
		loggerCache[name] = lp;
		return lp;
	}
}

(I call the above pseudo code, because I always forget the stl map find
syntax, and I'm too lazy to look it up :D )

Maybe something to add to the next version of log4cxx?


-----Original Message-----
From: Curt Arnold [mailto:carnold@apache.org] 
Sent: Tuesday, August 18, 2009 11:03 PM
To: Log4CXX User
Subject: Re: efficiencies of getLogger()

The typical pattern is to use a static logger member in a class which
results in getLogger() being called once per class during
initialization:

foo.h

class Foo {
    statlc log4cxx::LoggerPtr logger;
    void hello();
};

foo.cpp

log4cxx::LoggerPtr Foo::logger(Logger::getLogger("foo"));

void Foo::hello() {
   LOG4CXX_INFO(logger, "Hello");
}

Did you have a compelling reason to make repeated calls to getLogger()?

If your caching improved performance, there must be some potential for
optimization to getLogger() which should be doing roughly the same thing
internally.  Frequent calls to getLogger() is an atypical usage pattern,
so it hasn't been benchmarked.


On Aug 18, 2009, at 3:19 PM, david.weber@l-3com.com wrote:

> All,
>
> I was recently working on a project which was very time sensitive.   
> Milliseconds were prescious, and we had great interest in using 
> LOG4CXX, only in debugging problems (where time wasn't nearly as 
> critical).
>
> On the web site, I saw that getLogger("asdf") will return the same 
> object as a subsequent call to getLogger("asdf").  When we created 
> multiple objects of the same type, each of which had a logger instance

> with the same name, we profiled the code, and found that eacy 
> getLogger() call was taking quite a lot of time.  Unfortunately the 
> numbers are lost, but it was something like 100 us or ms.  These 
> numbers are a world apart, but when it came to creating ~1000 of my 
> own objects, the amount of time spent creating those loggers became 
> unacceptable.
>
> We ultimately found that by creating a caching mechanism using a 
> "loggerName" -> "loggerObject" map, made the subsequent calls much 
> more manageable.
>
> I was just wondering if anyone else has seen this sort of behavior.
>
> --dw