Does HashSet.equals() run in constant time?

Question

Just wondering if HashSet.equals(anotherHashSet) runs in constant time (also with a ConcurrentHashSet as argument), which I'm assuming it does for efficiency reasons. Can't see anything which mentions it, and a portion of the framework I'm building relies on the functionality (wouldn't want it to take too long!).

Edit: sorry, realised that there was no way that HashSet.equals() could ever run in constant time, since the elements can change while the hashcode for the elements in the map remains the same. Therefore, the best way to approach this problem would be to use hashcode. Does it reek of a code smell though?

Answer 1

Looking at a typical implementation shows that it does containsAll . Each check to contains is going to be O(1) and N of them are going to have to be made, so I reckon O(N).

Answer 2

As far as I see from the code - it runs in linear time. The collection is iterated and each element is compared:

equals(.. ) in AbstractSet calls containsAll(..) in AbstractCollection , which gets the iterator and calls contains(..) for each element, and that in turn calls map.containsKey(..) which is O(1) . So O(n) if I'm not mistaken.

Answer 3

Since the equals() contract of a Set requires that the elements of the two Set objects must be identical, I don't think that it's possible to correctly implement this in O(1) in the general case (ie without having additional restrictions on the content types, for example).

One obvious exception is that if the incomming set has a different size, then the equals() operation can easily finish in O(1) (as long as size() itself is O(1)).

You could write a thin wrapper that caches the hashCode() each time it's calculated (and discards it when the Set changes). This would allow you to have a constant run time in most of the cases where the two Set objects are not identical. When you have to equal Set objects (or in cases of hash collisions) you will still have a O(n) runtime.

Answer 4

How could it possibly run in constant time? The only sensible implementation (which is also the one used, which you can see if you check the API doc) is to iterate through one of the sets and for each element check whether the other one contains it, which is basically an O(n+m) operation.