I was talking about "String.equals()".
Kyle Wayne Kelly
(504)391-3985
http://www.cs.uno.edu/~kkelly
----- Original Message -----
From: "Beth Kelly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 9:50 AM
Subject: Re: Using Tomcat with MSAccess
>
> Kyle Wayne Kelly
> (504)391-3985
> http://www.cs.uno.edu/~kkelly
> ----- Original Message -----
> From: "William Kaufman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 09, 2001 7:14 AM
> Subject: RE: Using Tomcat with MSAccess
>
>
> > > <snip />
> > > > > "".equals(passwd)
> > > > > rather than
> > > > > passwd.equals( "" )
> > > <snip />
> > > > No you shouldn't. That's totally evil. For a start, you're
> > > > creating another String object by doing ""
> > > <snip/>
> > > <remark>
> > > As "" is a constant string, it is created just once. So there
> > > is not much overhead.
> >
> > True, other than the overhead of calling String.intern() when the class
is
> > loaded (JLS 3.10.5).
> >
> > > ("".equals might be even faster, because
> > > the jit can inline the method call, as the address of the object
> > > and the equals method is constant in this case.
> >
> > False. If the compiler can inline equals(), it can inline length(),
too.
> > (In fact, it's more likely to inline length(), since it's a far simpler
> > method.)
> I wonder if equals() is implemented with a bitwise "and". If that were
the
> case, then the first invocation of equals would be simpler than the length
> method (that is with delayed lazy evaluation).
> >
> > (And take a look at the source for String.equals(): at best, with
> comparable
> > inlining of the two methods, you've added an "instanceof" and a
downcast,
> > which likely swamps any time taken for the rest of the comparison.)
> >
> > -- Bill K.
>
>
