cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: log performance penalties
Date Mon, 19 Feb 2001 00:29:58 GMT
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

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 for more info on ASP for Java]

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message