You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/10/26 19:47:14 UTC

Re: cvs commit: jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/cli Token.java CLArgsParser.java CLOption.java CLOptionDescriptor.java CLUtil.java

Peter Donald wrote:
> 
> Hi,
> 
> I just noticed you were applying a number of optimizations that aren't really
> needed. Private members are implicitly final methods and thus there is no
> need to redundently mark them as such. Methods declared in a final class are
> also final methods and thus there is no reason to redundently specify final
> in this cas either.

Really, then why did I see 20% increase in performance?

> 
> And in a few places you actually put things like
> 
> >       /**
> >        * Convert to a string
> >        */
> >       public final String toString()
> >       {
> >           return new
> > StringBuffer().append(m_type).append(":").append(m_value).toString(); }
> >   }
> 
> which will actually cause a slow down. An optimizing compiler will actually
> work better with
> 
> return m_type + ":" + m_value;
> 
> because it is allowed to transform it into
> 
> final int size =
>   1 +
>   (( null != m_type ) ? m_type.length : 4) +
>   (( null != m_value ) ? m_value.length : 4)
> final StringBuffer sb = new StringBuffer( 9 );
> sb.append( m_type );
> sb.append( ":" );
> sb.append( m_value );
> 
> return sb.toString();
> 
> And things like
> 
> "You cannot lookup components " + "on a disposed ComponentManager"
> 
> are merged at compile time into
> 
> "You cannot lookup components on a disposed ComponentManager"
> 
> So there is no reason to join them in code - especially if it makes for huge
> long lines.
> 
> And things like the following are deliberate attempts to increase readability
> and should not be collapsed into one line.
> 
> final String message =
>   "Extension " + extensions[ i ].getExtensionName() + " is not local";
> throw new IllegalArgumentException( message );
> 
> --
> Cheers,
> 
> Pete
> 
> "The perfect way is only difficult for those who pick and choose.  Do not
> like, do not dislike; all will then be clear.  Make a hairbreadth
> difference and heaven and earth are set apart; if you want the truth to
> stand clear before you, never be for or against." - Bruce Lee
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

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


Re: cvs commit: jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/cli Token.java CLArgsParser.java CLOption.java CLOptionDescriptor.java CLUtil.java

Posted by Peter Donald <do...@apache.org>.
On Sat, 27 Oct 2001 03:47, Berin Loritsch wrote:
> Peter Donald wrote:
> > Hi,
> >
> > I just noticed you were applying a number of optimizations that aren't
> > really needed. Private members are implicitly final methods and thus
> > there is no need to redundently mark them as such. Methods declared in a
> > final class are also final methods and thus there is no reason to
> > redundently specify final in this cas either.
>
> Really, then why did I see 20% increase in performance?

where you compiling the bytecode with optimize on? which JVM are you using? 
which compiler were you using? hard to say without more information. It may 
be some brain dead behaviour from suns javac if you are using an old version 
of it.

-- 
Cheers,

Pete

------------------------------
Kitsch never goes out of style
------------------------------


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