You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/10/26 12:00:48 UTC
Re: cvs commit: jakarta-avalon-excalibur/src/java/org/apache/avalon/excalibur/cli Token.java CLArgsParser.java CLOption.java CLOptionDescriptor.java CLUtil.java
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.
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
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
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 Berin Loritsch <bl...@apache.org>.
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