I am using Long
/Integer
data types very frequently in my application, to build Generic datatypes. I fear that using these wrapper objects instead o
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.
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.
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.
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.