Take the 2-minute tour ×

What's the quickest to compare two strings in Java?

Is there something faster than equals?

EDIT: I can not help much to clarify the problem.

I have two String which are sorted alphabetically and EXACTLY the same size

Example: abbcee and abcdee

Strings can be long up to 30 characters

share|improve this question
Why would equals() be slow for you? –  BoltClock Sep 27 '10 at 16:01
Have you profiled your app, and was the conclusion that the hotspot in your code was caused by String.equals(...)? If you haven't profiled your app, why do you think String.equals(...) is (or could be) a problem? –  Bart Kiers Sep 27 '10 at 16:04
His question does not state that equals is slow. Just wondering if there is something faster than equals(). –  Sagar Sep 27 '10 at 16:05
his question does state that equals is slow (or at least that it's not fast) when he says 'or something faster than equals' –  KevinDTimm Sep 27 '10 at 16:21
Agreed - as it stands, this is a bad question. If you want something faster than equals(), then either you have some very specific performance requirements backed by measurements (in which case these must be posted before any appropriate answers can be given), or you actually don't (have unusual performance requirements), in which case you should just use equals(). Implying "equals isn't fast enough" without any justification gives people nothing to work with. –  Andrzej Doyle Sep 27 '10 at 16:55
show 7 more comments

6 Answers

up vote 15 down vote accepted

I don't expect that Sun Oracle hasn't already optimized the standard String#equals() to the max. So, I expect it to be already the quickest way. Peek a bit round in its source if you want to learn how they implemented it. Here's an extract:

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = count;
        if (n == anotherString.count) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = offset;
            int j = anotherString.offset;
            while (n-- != 0) {
                    return false;
            return true;
    return false;
share|improve this answer
This looks pretty optimized to me.... it would be theoretically possible to optimize it further for the OP's specific constraints (e.g. using the knowledge that the strings are already of equal length, and higher likelihood of different characters in the middle of the string), but you obviously can't do that in practice because the class is final and the fields are private .... +1 for digging out the source! –  mikera Sep 27 '10 at 18:26
I don't understand why they didn't compare the hashcode before doing a whole string compare. That would be faster. –  Stephan Mar 24 '12 at 9:39
@Stephan: that would have been more inefficient. The hashCode() loops over all characters of the string to perform the calculation. If the hashCode() was after all not the same, then the equals() would basically need to loop over all characters for the second time. –  BalusC Dec 21 '12 at 16:14
@BalusC That's only a part of the truth. Once calculated, the hashCode() method stores the hash code into an int, so the next comparison will be really fast. –  Stephan Jan 4 '13 at 8:33
add comment

It depends what you need. I think equals() is really optimized but perhaps you need something else faster than equals(). Take a look at this post.

share|improve this answer
add comment

If you can show that it's a significant bottleneck, which would surprise me, you could try

s1.hashCode() == s2.hashCode() && s1.equals(s2)

It might be a bit faster. It mightn't.

share|improve this answer
This was my first idea, too. Since string are immutual (is this really spelled right?) you're basically comparing constant ints here, which should be fast. Could be a problem only if the objects are equal most of the time, you could dynamically swap the implementation then. Too sad I don't have the jdk on this machine, would love to profile that now. –  atamanroman Sep 28 '10 at 8:35
it's "immutable" :) –  KevinDTimm Sep 29 '10 at 1:26
Yes, it is faster. But you need to do a null check before. –  Stephan Mar 24 '12 at 9:38
I doubt that would be faster unless you cache hashcode in some way. I think equals is faster than computing a hash code. –  jontro Apr 16 '13 at 10:23
@jontro java.lang.String caches its own hashcode. –  EJP Nov 25 '13 at 0:28
add comment

Compare Strings of same length faster using the hashcode:

public static boolean equals(final String s1, final String s2) {
return s1 != null && s2 != null && s1.hashCode() == s2.hashCode()
    && s1.equals(s2);

You can test it, my results are for 4000000 compare operations including identical, equal and different strings:

String.equals(String):  177081939
equals(String, String):  44153608
share|improve this answer
+1 I've been using this for a lot of "word crunching" and the perf is fantastic –  xchiltonx Dec 16 '13 at 22:08
add comment

As always, you will need to benchmark for your application / environment. And unless you have already profiled and idetified this as a performance bottleneck, it's probably not going to matter ("premature optimization is the root of all evil").

Having said that:

a.equals(b) is really fast for Strings. It's probably one of the most tightly optimized pieces of code in the Java platform. I'd be very surprised if you can find any faster way of comparing two arbitrary strings.

There are special cases where you can cheat and use (a==b) safely, e.g. if you know that both Strings are interned (and therefore value identity implies object identity). In that case it may be slightly faster than a.equals(b) - but again this depends on compiler/JVM implementation. And it's very easy to shoot yourself in the foot if you don't know what you are doing.....

share|improve this answer
p.s. I have just micro-benchmarked this, and (a==b) does beat a.equals(b) by a factor of about 2-4 times (30ns vs. 70-110ns) in my environment (Eclipse on Sun Java 1.6). YMMV, and usual caveats about micro-benchmarking do of course apply :-) –  mikera Sep 27 '10 at 16:39
Looking at the implementation code posted by @BalusC, I can see absolutely no heavy optimizations, nothing at all to warrant your statement. Granted, optimizing this already trivial code isn’t easy. But low-level, what could have been done to optimize is to move from char-wise to int-wise comparison (obviously this requires low-level tricks not readily available in Java, and it might not be faster after all). –  Konrad Rudolph Sep 27 '10 at 17:00
Hmmm It looks extremely tightly optimized to me, to the extent that e.g. they are re-using the string length as a negative loop counter (which is a classic low-level optimization). I can't see personally see any additional optimization that could be made, short of abandoning pure Java and dropping to a specialized native implementation (and it's possible that the JIT does this anyway....) –  mikera Sep 27 '10 at 18:11
You can use equals() and intern strings safely. The equals() method does check for identity. –  Stephan Mar 24 '12 at 9:16
add comment

Your Answer


