[log4perl-devel] Re: Log::Log4perl

[Mike S. <log...@pe...>]

On Mon, 14 Jul 2003, Kyle R. Burton wrote:

> Many thanks for implementing the Log4j clone.  We're in the process of
> integrating it into our software where I work.  During that process,
> some questions of efficiency came up and we started looking at the
> implementation.  For the actual logging methods, you're generating code
> based on the run-time configuration and leaving out most of the
> conditional checks, which is great.  Looking a bit further, we noticed
> that the is_* methods (is_debug) were not implemented using that
> approach and that raised the question of wether or not they could be.
> Could those methods be created to just return undef or 1?

The Log4perl core uses this snippet to create the is_xxx() methods:

  *{__PACKAGE__ . "::is_$lclevel"} = sub {
    return Log::Log4perl::Level::isGreaterOrEqual($_[0]->level(),
                                                  $$level
                                                  );
  };

which basically ends up in is_xxx() calling two subroutines, and one of
them runs a comparison of two integers. If this is a performance
problem, there's probably some room for us to improve the speed by

* running the comparison that isGreaterOrEqual() is performing right in
  the Logger code (but we'll have to give up this abstraction)

* replacing the level() call to accessing the hash value directly

* maybe providing functions (as you suggested) that return precompiled
  values. The only problem I see right now is that we've got arbitrary
  numbers of user-defined levels and would have to compile an arbitrary
  number of combinations.

Just curious: Did you run benchmarks to get a feel on how much of a
performance penalty is coming out of this?

-- Mike

Mike Schilli
log...@pe...
http://perlmeister.com
http://log4perl.sourceforge.net