On 8/9/10 11:13 AM, Pellerin, Clement wrote:
In JDK 1.5, String.equals() begins with:
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
...
Since String is a final class, the JIT compiler is free to in-line
String.equals()
This is such a common case, I bet the JIT compiler team made it a special case
to in-line at least the beginning of String.equals() at every invocation site.
This was my guess as well.
If your test bed only uses intern Strings this will return early with the same
behavior as == for equal strings.
Not necessarily, there are a number of not equal checks in there that
should, in theory, perform better if you only use == only. In such a
case, the use of != will just be a single check while !equals() will
result in a char-by-char comparison.
Is it possible your test bed calls String.equals() with an overwhelming
percentage of equal strings?
I'd have to look at exactly where all calls occur, it's possible but if
my memory is currently serving me well, it's not the case.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
