Choosing right collection

-

                The performance of code can be affected significantly by choosing the right collection implementation. Regarding the correct and efficient use of the Java Collection classes, a significant performance setback comes from the low utilization of implementation classes other than ArrayList and HashMap. These two implementations are used for almost everything, although different implementations would be more appropriate in some situations.

The following rules should be applied to select the appropriate collection class:

·        Use ArrayList to collect data in order of occurrence (append operation only). Adding or removing elements at the bottom of the list is very fast on ArrayLists and LinkedList, but the LinkedList puts a high load on the garbage collector. This is the most common use case for lists.

·        Use LinkedList to maintain lists whenever elements have to be inserted or removed at positions other than the the bottom of the list. Inserting or removing elements is very slow for ArrayLists because at average half of the elements in the list have to be shifted.

·        Use LinkedList to maintain lists that contain only very few elements and have a lot of instances (for example, 5000 lists with 3 elements each). An ArrayList wastes space for unused slots, a LinkedList needs more bytes per element.

·        Never use LinkedList for index-based access. Use only the implementations of List that also implement the (tag-)interface RandomAccess.

·        Use Set types like HashSet and TreeSet to maintain lists that contain no duplicates (for example, observers). Searching is very quick for sets: O(log n) instead of O(n). The Set implementation LinkedHashSet combines the preservation of the insertion order of the List type with the quick lookup of the HashSet type.

The values in the table below show the memory requirements of ArrayList and LinkedList during an append-only operation. The LinkedList is faster in filling the list but takes much more time to clean up afterwards. This is due to the complex memory-structure of a linked list (many objects, many references) and therefore a lot of work for the garbage collector.

So the real behavior depends largely on the load that is put on the system. When the CPU load is not high and garbage collections are not frequent, the garbage collection overhead of the LinkedList is no problem.

When garbage collection takes place as the CPU is busy the time, the garbage collector needs to work off the memory structure (GC Full Cycle Time in the table) will be added completely to the execution time of the application, because the program execution is interrupted until the memory is acquired by the garbage collector.

 

 

Appending 10.000.000 elements to a list.

List Class

Memory

Garbage

Execution Time[1]

GC Time2

GC Full Cycle Time3

ArrayList

45MB

89MB

620 ms

< 1ms

140 ms

LinkedList

234MB

0MB

460 ms

230 ms

1.550 ms

[1] no garbage collections in the background

2 time required to collect the objects in the list after the reference to the list has been cleared

3 time the garbage collector took to traverse the heap for releasable objects (without finding any)

 

 

Regards,

Vamsi.

 

 

Comments

Post a Comment

Popular posts from this blog

What's New in JAVA 8

-
Finally Java 8 released under oracle leadership with many features and enhancements. Though some of the popular JSR's like JSR 294 (Jigsaw) are deferred again to next release, Java 8 still be the largest ever upgrade to java after it was introduced in 1996.  Lets see one of those improvements.  Performance improvement of java.util.HashMap under high hash-collision conditions : Just to give a little background : HashMap is used to store key-value pairs in no.of buckets technically 'Entry' objects . Entry is an inner class of HashMap. Please click  here to see the source code in java 7. Each bucket has a unique number called hash code. When you try to put a key-value pair into the map, the hashmap will look at the hash code of the key, and store the pair in the bucket of which the identifier is the hash code of the key. Let's say if hash code of two keys are same then hash-collision occurs. Till now (prior to Java 8), hash collision is addressed by creati
Read more

Singleton Design Pattern

-
We need to create a class which can have only one instance at any time. Solution 1: public class MySingleton { private static MySingleton singleton= new MySingleton(); private MySingleton(){ System.out.println( "Object Created" ); } public static MySingleton getMySingleton(){ return singleton; } } Let's create the object when we need it, not at the time of loading the class. Solution 2(with Lazy loading): public class MySingleton { // Line : 1 private static MySingleton singleton=null; // Line : 2 private MySingleton(){ System.out.println( "Object Created" ); } // Line : 3 public static MySingleton getMySingleton(){ // Line : 4 if(singleton == null) // Line : 5 { singleton = new MySingleton();
Read more

Internals of JSF

-
Once jsf project set up properly i.e entries in the web.xml,jsf related jars in lib folder of your web app( setting up jsf project ) we have to create a faces-config.xml to make our set up into a full fledged jsf application. Creating Faces-config.xml :: In the name itself telling us that it contains all the configurations needed for all jsf pages.In fact we don't need to create the file with the same name.We can create it with any name and we have to mention same as a context parameter in the WEB.xml ( setting up jsf project ).Now its the time to jump into the detailed view.   Fallowing are the two main components that we use frequently. 1)Managed Beans It represents a Java bean that will be instantiated dynamically at the run time by JSF container.We can achive inversion of control in JSF. Ex: Class User{ private String name; private String Address; //setters and getters for both properties } Declaration in faces-config.xml   <man
Read more