Can using non primitive Integer/ Long datatypes too frequently in the application, hurt the performance?

I am using Long/Integer data types very frequently in my application, to build Generic datatypes. I fear that using these wrapper objects instead of primitive data types may be harmful for performance since each time it needs to create objects which is an expensive operation. but also it seems that I have no other choice(when I have to use primtives with generics) rather than ju开发者_JAVA技巧st using them.

However, still it would be great if you can suggest if there is anything I could do to make it better. or any way if I could just avoid it ??

Also What may be the downsides of this ?

Suggestions welcomed!

---

Repeat after me. "Creating an object in Java is not an expensive operation".

You are prematurely optimizing your application. A better approach is to implement it in the natural way using Integer and Long, then profile it to determine where the bottlenecks are. If the profiler tells you that use of Integer and Long is a performance issue, then look at ways to cure this.

---

If you determine that Integer and Long really are an issue, here are some things you could do:

• Look for a class library that implements "collections" of primitive types; e.g. Trove. But beware that the APIs of such collection types won't be compatible with java.util.Collection and its descendants.

• Use Integer.valueOf(int) and Long.valueOf(long) rather than new Integer(int) and new Long(long). The valueOf methods use a cache of frequently used objects to reduce the number of object creations.

---

@Rex Kerr's comment is that this is horrible advice. He is (I think) saying that the OP should optimize his application to reduce the use of Integer and Long before he knows that this will be a performance concern. I disagree.

• At this point (when he asked the question), the OP didn't know that his application needed optimization. If the application runs "fast enough" without any optimization, then any developer time spent optimizing it would be better spent on something else.

• At this point, the OP doesn't know where the performance bottlenecks are. If they are not in the handling of these values, then optimizing this aspect will be a waste of time. Note that generally speaking it is a bad idea to rely solely on your intuition to tell you where the bottlenecks are or are likely to be.

• @Rex Kerr posits that it would be a lot of work to modify/restructure the code to fix performance issues due to over-use of Integer and Long. That's simply not true. A decent IDE makes it easy to make this sort of change in a small to medium size application.

---

If you have many collections, or large collections, you are likely to have performance problems. See http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf.

If you have many collections, or large collections, or many large collections of boxed types (e.g. Integer, Long) there are alternatives: one is the Mahout Collections library, from http://mahout.apache.org. Mahout collections have open hash tables, which address many of the issues in the linked PDF, and collections that store little-i-integers, etc. Another is Trove, if GPL doesn't bother you.

If you are not sure that your code qualifies as 'many,' 'large', or 'many large', then by all means use a profiler and see what's going on.

---

Like others say,

Premature optimization is root of evil.

Having said that, prefer primitive types to boxed types wherever you can.

UPDATE: Might also add that according to developers that work with high-performing code (like distributed cache) boxing can indeed become a performance problem quite frequently. I also worked with high-performing apps. but have never identified boxing as a worthy optimization place yet.

---

You are better off profiling your application and looking at where your bottlenecks and hot spots are. These are very hard to predict most of the time. IMHO If you are not measuring, you are just guessing.

However, if you determine that using primitive in a collection would be more efficient, I suggest you try http://trove.starlight-systems.com/ It can make a big difference when it really matters but for 90% of the time, it doesn't.