james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: isLogEnabled() and StringBuffer
Date Tue, 14 Nov 2006 08:38:56 GMT
On 11/14/06, Joachim Draeger <jdraeger@gmx.de> wrote:
>
> Hi!
>
> Am I hitting another controversy topic? ;-)

We will see ;-)

>
> Example from ImapHandler.java
>
>         catch ( IOException e ) {
>             if ( getLogger().isErrorEnabled() ) {
>                 StringBuffer exceptionBuffer =
>                         new StringBuffer( 256 )
>                         .append( "Cannot open connection from " )
>                         .append( remoteHost )
>                         .append( " (" )
>                         .append( remoteIP )
>                         .append( "): " )
>                         .append( e.getMessage() );
>                 getLogger().error( exceptionBuffer.toString(), e );
>             }
>             throw e;
>         }
>
> IMHO this blows up the code and reduces the readability by only bringing
> a negligible performance enhancement.
> IMO the bottleneck is IO and in the big frameworks (JavaMail ;-) and not
> in simple string computation.
>
> Better readability will bring our users less bugs and costs only a few
> microseconds.
>
> IMO StringBuffer is only mandatory when dealing with really big Strings
> (like message headers/body) or when doing really much concats.
> I would use isDebugEnabled() only inside a loop and not in a per command
> issue.
> To make it clear: I'm not proposing refactoring all around James. I just
> don't want to make extensive use of isLogEnabled() and StringBuffer().
> I'm going to remove it from Imap code where I think it brings more
> readability.
>
> WDYT?

AFAIK, String concatenations on a single line (not in loops or more
complex situations) are optimized by the compiler to actually use
StringBuffer in byte code.

I also agree that the performance gain can be neglected.

Memory garbage should not be a problem any longer in the light of
generational GCs.

So, I would support to simplify this in new code.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message