CODEWITHSUNDEEP
javastring
Mediator
Mediator

Reputation: 15388

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

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

Upvotes: 31

Views: 48097

Answers (7)

ungalcrys
ungalcrys

Reputation: 5620

I had tries different combinations for string comparison (code here):

1. s1.equals(s2)
2. s1.length() == s2.length() && s1.hashCode() == s2.hashCode() && s1.equals(s2)
3. s1.hashCode() == s2.hashCode() && s1.equals(s2);
4. s1.length() == s2.length() && s1.equals(s2);

I used strings of 40 chars length, in 10000000000L iterations and before any iteration I reinitialized the strings.

for equal stings I got:

equal: 2873 milis ???
equal: 21386 milis
equal: 7181 milis
equal: 2710 milis ???

for same size strings but last char different I got:

different: 3011 milis
different: 23415 milis
different: 6924 milis
different: 2791 milis

for different sizes, almost same strings but one char added at the end for s2:

different size: 3167 milis
different size: 5188 milis
different size: 6902 milis
different size: 2951 milis

seems to me it is best to use first a string.length() comparison before equals().

But this will not matter almost at all because this is the case where I have 10^10 string comparisons with 40 chars length and what is bizarre for me is the case where for equal strings I have a better speed when I compare the string length first.

Upvotes: 5

Stephan
Stephan

Reputation: 4443

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

Note: Calculating the hashCode of a new string object takes some computation time and afterwards the hashCode is stored in the object. So my suggested improvement will only be faster than the default compare if string objects are reused. In my application I am using String constants and store strings in collections. Multiple comparisons of strings using my method are actually faster for me, but it may not be in general.

If the method is used with new strings all the time like compare("a", "b"), it won't be an improvement.

So the fastest way of comparing strings depends on:

  • Whether your string objects are reused (like from a collection) or are always new (like from an input stream)
  • Whether your strings have different lengths
  • Whether your strings differ at the start or the end of the string
  • Your programming style, how much constants are used
  • Your use of String.intern()

Ignoring those facts, the majority of all programs will be fine with String.equals().

Upvotes: 28

Flow
Flow

Reputation: 24083

Simple answer

String.equals(Object)

I'm pretty sure (this answer has some references) and it's very likely that the JIT will have an intrinsic for String#equals, which means it would be able to replace the call with specially crafted machine code for the architecture your JVM is currently running on.

Upvotes: 1

user207421
user207421

Reputation: 311052

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.

Upvotes: 4

mikera
mikera

Reputation: 106401

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.....

Upvotes: 0

oyo
oyo

Reputation: 1924

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.

Upvotes: 3

BalusC
BalusC

Reputation: 1109865

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) {
                if (v1[i++] != v2[j++])
                    return false;
            }
            return true;
        }
    }
    return false;
}

Upvotes: 36

Related Questions