This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
If you're still interested in their relative performance, I would guess that equals is faster, because it only needs to compare the individual characters for equality, and not consider up-/downcasing it and then comparing that as well. That shouldn't make a big difference, though. The source of java.lang.String will tell you for sure.
To be fully sure, you'd have to write a Benchmark. Writing a good one is an art, though. And it still wouldn't tell you wether it actually had any significant impact on the system you are developing - for that you needed to run it through a profiler.
"You don't need to care" is a quite good working hypothesis, though... [ July 06, 2005: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
For most purposes the question is purely academic and could also change from one version of the jvm to another. For most purposes both are very fast. Plus, as another poster said they return different results, so you just can't swap them.
Here are some results I found using google on the matter. As, I recall Jack Shirazi's "Java Performance Tuning" book dicusses the matter too.
compareTo is two to three orders of magnitude faster than either of the equals methods. In my study - not shown here - I have found that the method call equalsIgnoreCase of the class String is a lot faster than the method call equals of the same class when the majority of the compared data have different lengths. There is a good reason for this, of course. The equalsIgnoreCase first checks the length of the two strings
[ July 08, 2005: Message edited by: steve souza ] [ July 08, 2005: Message edited by: steve souza ]
Excellent point, Steve. Note, though, that (as you said!) these results can change. I just looked at the source for 1.4.2_08, and String.equals() does indeed check the lengths first, and equalsIgnoreCase() does a lot more work than equals() does, so it looks as though equals() is now the faster method.