cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: AW: log performance penalties
Date Mon, 26 Feb 2001 23:12:25 GMT
Berin Loritsch wrote:
> 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.

I belive this is because javac knows at compiletime that LOG cannot be 
anything else that false.

> > >
> > >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;
> > }

Well, haven't tried it but I think this will not produce the same results as 
the example above from Stefano because javac might not necessaraly know the 
value of Cocoon.LOG at compile time (I must admit I haven't checked it 
out).

> >
> > 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}";
>     ........
> }

I propose we should be able to configure the amount of log information by 
means of the log-level in the web.xml file AND have it perform accordingly 
(think of a C2 binary distribution which should be available someday).

> 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();
>     ....
> }

Giacomo

Mime
View raw message