Integer auto-unboxing and auto-boxing gives performance issues?
Asked Answered
A

3

12

We are currently doing some iterations and other operations using x++; where x is an Integer and not an int.

Operations may be repeated throughout some user operations on our system but nothing too complex or numerous like a Mathematical application, maximum up to 10000 times per user transaction..

Will this unboxing and later boxing affect our performance by some noticeable milliseconds?

Annmaria answered 17/5, 2011 at 21:29 Comment(2)
To apply Erhan's answer to your situation, unless you must store the value in a Collection between increments, use a primitive int. You'll need to supply more details or code to allow any deeper analysis.Reedbuck
@David I agree, but even for collections I personally find myself frequently using GNU Trove (trove.starlight-systems.com) when primitives are involved. I rarely use Java's primitive wrappers, although my bias happens to be in compute-heavy programs where the difference (in time and memory) matters a great deal.Superposition
P
19

http://download.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

"The performance of the resulting list is likely to be poor, as it boxes or unboxes on every get or set operation. It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.

So when should you use autoboxing and unboxing? Use them only when there is an “impedance mismatch” between reference types and primitives, for example, when you have to put numerical values into a collection. It is not appropriate to use autoboxing and unboxing for scientific computing, or other performance-sensitive numerical code. An Integer is not a substitute for an int; autoboxing and unboxing blur the distinction between primitive types and reference types, but they do not eliminate it."

Pawl answered 17/5, 2011 at 21:31 Comment(0)
P
1

Yes, there is a performance impact. The equivalent code produced for ++x involves creating a new Integer object each time. x++ additionally creates a temporary variable to store the previous integer reference, and some manipulation. You can verify this by disassembling the class file.

Pianola answered 17/5, 2011 at 21:54 Comment(0)
T
1

The speed of auto-boxing depends on the JVM version you're using, the range of the actual numbers you're working with, and your GC settings. See this really interesting in-depth article on (un)boxing performance.

Basically, the JVM caches a number of the Integer objects so it doesn't need to create the "common" ones every time. You can configure this cache size.

As for the specific question: Will your operation be milliseconds slower if you use primitives versus autoboxing? This entirely depends on the size of the list and how often it gets called. It should be easy (i think!) to test the primitive alternative's performance.

Threw answered 17/5, 2011 at 23:49 Comment(1)
Good info in the link!Kalamazoo

© 2022 - 2024 — McMap. All rights reserved.