Brian there is some cost for sure but I did not do a real benchmark. When I did search for it, I came across : http://stackoverflow.com/questions/423704/java-int-or-integer/423856
the last answer indicate that auboxing 2000 Integer add 0.5 ms... yes it's not much but if you are doing a lot of such operation it starts to adds up especially on a server side web apps/web services. The Sun documentation at : http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html even indicates : > *Finally, there are performance costs associated with boxing and unboxing, > even if it is done automatically.* The alternative will be for the code to automatically go from scalar to object without relying on the VM that needs to do the extra step. For example in the following generated code: public void putToResult(String key, int val) { if (this.result == null) { this.result = new HashMap<String,Integer>(); } this.result.put(key, val); } we could bypass the autoboxing on the last line by using: this.result.put(key, new Integer(val)); or maybe have some helper class that have some pre-cached Integer so it avoids constantly creating the same Integer over and over. Maybe it could be an extra options when getting the code generated... What do you think ? Stéphane On Wed, Jul 15, 2009 at 4:15 PM, Bryan Duxbury <[email protected]> wrote: > Is there a measurable performance difference here? I'd be willing to do > anything that improved performance, presuming that it was not completely > onerous to write code or use it. > > What is the alternative to autoboxing? > > > On Jul 15, 2009, at 2:02 PM, Stephane wrote: > > I am looking at Thrift for some project and I have noticed that the java >> code generated by thriftc is relying on the Java VM for autoboxing... I am >> in some way surprise to find many spots where it's happening, and at first >> my Eclipse project was not compiling since for performance reason my >> default >> project settings were to generate a compilation error when detecting >> autoboxing. >> Is there any plan in the future to avoid autoboxing and rather generate >> some >> java code that do not have the -small- penalty of getting the VM do the >> extra work ? I know the cost is small but any performance gain should be >> considered no ? >> >> Stéphane >> > >
