Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How ++ operator works for Integer class

 
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
Saloon Keeper
Posts: 15282
39
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
Saloon Keeper
Posts: 15282
39
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic