Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How ++ operator works for Integer class  RSS feed

 
Vaib's V. Manwatkar
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I got this link from SCJP forum. http://www.certpal.com/blogs/2009/08/autoboxing-unboxing-gotchas/

This link is having an example for Autoboxing/Unboxing as follows:

private void loopDeLoopUsingInteger()
{
long past = System.nanoTime();
Integer iCounter=0;
for(iCounter=0; iCounter<10;iCounter++)
{
iCounter++;
}
long now = System.nanoTime();
System.out.println(now - past);
}

I searched on net how the ++ operator works for Integer but could not get any help.
Can anybody help me understand this.

Thanks in advance,
Vaibhav
 
Peter Taucher
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) Welcome
2) UseCodeTags
3) I don't think that's a beginner question, why didn't you ask it in the SCJP forum?

A lot of boxing/unboxing occurs. For every incrementation the Integer is unboxed, incremented and boxed again. Same goes for the condition - to compare with 10 in each time the Integer is unboxed. That's why using Integer that way is very slow... (correct me if I'm wrong)
 
King Goddard
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know it works the same way though at least functionally.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 15860
80
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter Taucher wrote:A lot of boxing/unboxing occurs. For every incrementation the Integer is unboxed, incremented and boxed again. Same goes for the condition - to compare with 10 in each time the Integer is unboxed. That's why using Integer that way is very slow... (correct me if I'm wrong)

It indeed boxes and unboxes a lot, but the slowness might be less than you think in reality, because the JVM might do some smart optimizations under the covers. But still it's better to use a primitive int instead of Integer as a loop counter.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, admittedly the article was nearly a year ago, but it's claiming a 16x time difference. Trying it locally I get a pretty darn noticeable difference (~8 seconds)--with the caveat that I didn't check the bytecode to see if, say, the primitive version was being optimized differently, etc. Without disassembling, and understanding precisely what the JIT is doing, I'm very suspicious of micro-benchmarks like this, particularly when it's a loop that does nothing but increment the loop counter twice each time around.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 15860
80
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Sun's JVM, the Java compiler (javac) does very little optimization, so I wouldn't expect to see optimizations in the bytecode; the HotSpot JIT contains most of the optimizations. It's hard to see what exactly the JIT does to the bytecode.

By the way, I found some interesting documentation on OpenJDK HotSpot internals. Ah, I must put this page about microbenchmarks in my list of favorite links, for when people start making conclusions about their benchmarks again without thinking of all the subtleties...
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!