cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: AW: log performance penalties
Date Fri, 23 Feb 2001 16:55:39 GMT
Carsten Ziegeler wrote:
> 
> > Stefano Mazzocchi [mailto:stefano@apache.org] wrote:
> > Tagunov Anthony wrote:
> >
> >> Sure, this approach is not universal..
> >>
> >> 1)
> >> As for number of parameters:
> >> i personally see no trouble in
> >> having 9 .log methods with number of parameters from 1 to 9 respecitvely, if
> >> it saves performance! And I beleive there's a sane limit that a regular
> >> log request does not come over..
> >
> >The solution is to remove the code completely.
> >
> >I'm not sure how many of you know this but this Java code
> >
> > final boolean LOG = false;
> >  if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
> >test");
> >
> >is compiled into
> >
> >  final boolean LOG = false;
> >
> >that's it! the code is gone! try it yourself with javap.
> >
> >This is the fastest solution available: no code executed no time lost.
> >
> >Of course, this requires a pretty good 'coding style' and coherence
> >thruout the entire code and makes it more unreadable for those who are
> >not aware of this java feature... but it's much better than having
> >things like
> >
> >// #ifdef LOG
> > if (logger.debugIsActive()) logger.debug("this" + is + "a test");
> >// #endif
> >
> >which must be preprocessed before generating the code.
> >
> >Of course, the real solution would be to use AspectJ to code Cocoon, but
> >I'd rather wait until AspectJ stabilizes before moving to aspect
> >oriented programming. [for those of you who don't know what I'm talking
> >about, look at www.aspectj.org for more info on ASP for Java]
> >
> I would suggest we start converting/implementing the logging in the way Stefano suggested.
> Either by
> 1. if (logger.debugIsActive()) logger.debug(...)
> or
> 2. if (LOG && logger.debugIsActive()) logger.debug(...)
> 
> Allthough I see the advantage in 2. I would vote for 1., because logging can be controlled
simply by changing the configuration without recompilation. Number 2. would require changing
many places for turning LOG on and off.
> Or has something like
> class Cocoon {
>   public static final boolean LOG = true;
> }
> 
> with if (Cocoon.LOG && logger.debugIsActive()) the same effective? Then I could
imagine to use 2.
> 
> What do you think? In which way should we start converting?

The final solution you proposed would be best, as we would not have
a Cocoon Logger class floating around.  Don't be locked into
public static final and setting it there.

You have two choices with that approach:

Modify Ant to build a LOGGABLE version or LOG_DISABLED version of
Cocoon.  This has the advantage of placing the boolean in the
Constants file:

public interface Constant {
    String LOG = "{$DO.LOGGING}";
    ........
}

Modify an object to provide a static function that records whether
to log or not:

public class LogUtil {
    public static Logger getLogger();
    public static void setLogger();

    public static boolean doLog();
    ....   
}

Mime
View raw message