Re: performance of HashSet with strings and integers

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 07 Oct 2009 07:06:47 -0700

Message-ID:

<7r6dnQKvwePoPVHXnZ2dnUVZ_o-dnZ2d@earthlink.com>

Frederik wrote:

Hi,

I thought of replacing strings with integers in some code I wrote,
because I believed it would benefit performance. But before doing so,
I made a small test class:

public class testStringSetVsIntSet {
    public static void main(String[] args) {
        long time;
        boolean b;
        Set set;

        Integer I1 = new Integer(100), I2 = new Integer(500);

        set = new HashSet();
        set.add(I1);
        set.add(900);

        time = System.currentTimeMillis();
        for (int i=0; i<50000000; i++) {
            b = set.contains(I1);
            b = set.contains(I2);
        }

        time = System.currentTimeMillis() - time;
        System.out.println("Time 1: " + time);

        String headStr = "Head";
        String agentStr = "Agent";
        String qualifStr = "Qualif";

        set = new HashSet();
        set.add(headStr);
        set.add(agentStr);

        time = System.currentTimeMillis();
        for (int i=0; i<50000000; i++) {
            b = set.contains(headStr);
            b = set.contains(qualifStr);
        }

        time = System.currentTimeMillis() - time;
        System.out.println("Time 2: " + time);
       }
}

But to my surprise, the second loop with the strings appeared to be
twice as fast as the first one with the integers! (first loop 3
seconds, second 1.5 seconds)
I didn't expect this because calculating the hashcode for a string is
normally slower than for an integer (every string character is taken
into account) and I thought the "equals" method for a string should be
slower than for an Integer as well.
Can anybody explain this to me?

The String implementation caches the hash code, so only the first call
for each instance incurs any cost for calculating it.

The equals method only gets called if the HashSet contains an element
whose hash code is equal to the probe's hash code but that is not the
same object as the probe. That is very unlikely in a test with so few
objects.

I strongly suspect that your real use of the HashSet is significantly
different from your benchmark. The large number of contains calls with
the same key, the small number of distinct strings, and the lack of any
case in which you have two distinct but equal objects may all affect the
results.

Patricia