Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
From: Giacomo Pati <giacomo@apache.org>
Organization: Apache Software Foundation
Date: Thu, 15 Feb 2001 22:08:14 +0100
Content-Type: text/plain;
  charset="us-ascii"
To: cocoon-dev@xml.apache.org
References: <3A8BEC74.8D935CF8@apache.org>
In-Reply-To: <3A8BEC74.8D935CF8@apache.org>
Subject: Re: log performance penalties
MIME-Version: 1.0
Message-Id: <01021522081404.01499@lap1>
Content-Transfer-Encoding: quoted-printable

Stefano Mazzocchi wrote:
> I'm looking at the changes made to Cocoon while I was away:
>
> are you guys aware of the fact that something like
>
>   getLogger().debug("Making URL from " + location);
>
> is translated by java compilers into
>
>   StringBuffer sb =3D new StringBuffer("Making URL from ");
>   sb.append(location);
>   getLogger().debug(sb.toString());
>
> which generates
>
>  1) a new stringbuffer object
>  2) a new String
>
> even if debug log channel is disabled?
>
> Probably so, but just to make sure.

I'm fully aware of that but it has helped alot finding bugs because C2 is=
 a=20
very distributed exeption throwing and eating beast :). Most of the loggi=
ng=20
stuff come from Berin and I've found that it was easy to debug now.

> The only way to do it well is by wrapping the whole call around a log
> channel test such as
>
>  if (getLogger().debugIsActive()) getLogger().debug("Making URL from " =
+
> location);

I've thought of how to weaken that and your idea seems to be one solution=
=2E=20
The radical solution I had was to pipe the code through a filter that=20
eliminates all the debug loggin stuff (but in fact this would be a loss)

>
> FYI, doing this in JServ 1.0 resulted in a 20% performance improvement.
>
> I understand that performance fine tuning is very low priority right no=
w
> (and rightly so!) but please, keep this in mind from start or profiling
> will be a major pain in the ass later on.