views:

2626

answers:

8

I may be teaching a "Java crash-course" soon. While it is probably safe to assume that the audience members will know Big-O notation, it is probably not safe to assume that they will know what the order of the various operations on various collection implementations is.

I could take time to generate a summary matrix myself, but if it's already out there in the public domain somewhere, I'd sure like to reuse it (with proper credit, of course.)

Anyone have any pointers?

+3  A: 

Here is a link I found to be useful when discussion some very common Java objects and how much their operations cost using Big-O notation.

http://objectissues.blogspot.com/2006/11/big-o-notation-and-java-constant-time.html

Nick
+2  A: 

Though not in the public domain, the excellent Java Generics and Collections by Maurice Naftalin and Philip Wadler lists runtime information overviews in its chapters on the different collection classes.

Fabian Steeg
+2  A: 

The Javadocs from Sun for each collection class will generally tell you exactly what you want. HashMap, for example:

This implementation provides constant-time performance for the basic operations (get and put), assuming the hash function disperses the elements properly among the buckets. Iteration over collection views requires time proportional to the "capacity" of the HashMap instance (the number of buckets) plus its size (the number of key-value mappings).

TreeMap:

This implementation provides guaranteed log(n) time cost for the containsKey, get, put and remove operations.

TreeSet:

This implementation provides guaranteed log(n) time cost for the basic operations (add, remove and contains).

(emphasis mine)

matt b
I disagree with the HashMap part. I know Sun's position, but... get for example must call obj.equals(key), which could be linear in the size of the objects contained. Consider that you typically have to read the fields for this comparison. The exceptions would be integers or strings (interned)???
Overflown
First of all, if they were wrong, it ought to be not too hard for you to create a test case that disproves the constant-time performance? Second, if you look at the source code for HashMap, it does not call equals() against each key in the map - only when the hashcodes are equal.
matt b
If you read the quote above, it says it's constant-time "assuming the hash function disperses the elements properly among the buckets". From CS theory, hash tables have constant time operations when the hash function is "good" (which happens on average), but may take linear time in the worst case.
newacct
@Overflown - technically, it doesn't matter how long obj.equals() takes from a complexity perspective, as that is just part of the "constant" with relation to the number of items in the collection.
mikera
+2  A: 

The book Java Generics and Collections has this information.

The bottom of the javadoc for the java.util package contains some good links:

toolkit
+2  A: 

The guy above gave comparison for HashMap / HashSet vs. TreeMap / TreeSet.

I will talk about ArrayList vs. LinkedList:

ArrayList:

  • O(1) get()
  • amortized O(1) add()
  • if you insert or delete an element in the middle using ListIterator.add() or Iterator.remove(), it will be O(n) to shift all the following elements

LinkedList:

  • O(n) get()
  • O(1) add()
  • if you insert or delete an element in the middle using ListIterator.add() or Iterator.remove(), it will be O(1)
newacct
A: 

Java in a Nutshell, Fifth Edition from O'Reilly also contains a run down of the best, worst, and average times of typical collections.

James McMahon
A: 

Just for benefit of others this link has a section section covering almost all collections and their Big O Notation list for most of the important methods.

BigONotationJavaCollections

Hope this help

Kzvi
+2  A: 

I found this cheat sheet on the Collections framework to be pretty useful - contains Big O summary information for all implementations.

http://www.coderfriendly.com/wp-content/uploads/2009/05/java_collections_v2.pdf

Source

Ben J