Comments on: Why YOU should use Integer.valueOf(int)

by: Illia

Wed, 03 Sep 2008 14:13:33 +0000

I tested not in range (actually most of the data we have are such). I used for cycle variable of the same type (int for Integer, long for Long)

new Integer
avg = 11 ns
Integer valueof
avg = 13 ns

you say 2 nanoseconds?
13/11 = 1.18, neraly 20% or 1/5 longer

Long is different (you can see source code why)

new Long
avg = 12 ns

Long.valueof
avg = 20 ns

now nearly twice longer

by: Use .intValue() or .equals() « public static overflowing main

Sat, 01 Dec 2007 16:26:17 +0000

[…] Later I came across this blog post. When I completed reading it I could not agree more with my mentors line of reasoning. […]

by: Adam Goucher » Blog Archive » PMD, IntegerInstantiation and a Red Herring

Fri, 17 Aug 2007 12:13:04 +0000

[…] Yesterday I did a bit of exploring how well PMD’s Eclipse plug-in integrates into our development tools / process. Even if you are not planning on implementing static analysis and you are a java shop, you owe it to yourself to become familiar with the rules that PMD and other such tools utilize. Why? Because while we have in technology a great tradition of reinventing the wheel it is generally not too efficient and managers tend to frown on it too. So why do you want your group to re-learn in their context what others have learned in similar ones? You will also learn more about the underlying technology of the product you are testing. That is certainly not a bad thing either. Back to the original point. The code I work against is triggering a pretty sizable amount of hits to the IntegerInstantiation rule which they summarize as IntegerInstantiation: In JDK 1.5, calling new Integer() causes memory allocation. Integer.valueOf() is more memory friendly. I can’t argue with the whole ‘memory friendly’ aspect, but we’re using Java 1.4 which makes this a false positive (something you learn to live with in the world of static analysis. But through the process I extended my knowledge of how Java works; initially from the description of the rule, and further through articles I found like this which is absolutely a Good Thing™. […]

by: Pure Danger Tech » Blog Archive » One more look at Double-Checked Locking

Fri, 15 Jun 2007 18:32:58 +0000

[…] I’ve blogged before on one instance where this is used in the JVM itself. Integer.valueOf() lazily caches Integer objects from -128 to 127 (as required by the JVM specification). But, you don’t want to incur the cost of creating the cache unless it’s needed, so the cache is initialized on demand via a private static class. […]

by: Alex

Sun, 04 Feb 2007 04:10:03 +0000

Tim, good catch on the first point - had a copy/paste error there. I’ve re-run and updated the numbers (not much difference really).

Second, I based my original recommendation on the JDK javadocs which say “If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values.” I still think this is good advice if you heed the first clause regarding whether a new Integer is required (see the prior WeakHashMap comment).

Also, I did run a quick test to look at the difference if you are requesting a value in the cached range vs out of the cached range:

new (regardless): 15 ns
valueOf (in range): 7 ns
valueOf (not in range): 16 ns

So, if you always use valueOf and you request a value out of the cached range, you are costing yourself a nanosecond each time. It’s hard to see how 1 ns (or even an 8 ns savings will help you that much), but as I’ve said above, I think the benefit is more in the space savings than the speed. And the larger point is that using a factory method allows the implementation to better optimize the implementation (better caching, native calls, magic JDK hooks, who knows what) in the future without you changing your own code.