Brian I will see if I have time to come up with a benchmark, which should be something I can do at first... For the patch that may take longer :-)
I may write a simple structure and modify/fix the autoboxing manually and run some test, so we can compare the autoboxing in a Thrift context. I'll post my result. Stéphane On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <[email protected]> wrote: > Comments inline. > > On Jul 15, 2009, at 4:43 PM, Stephane wrote: > > 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. >> > > Interesting. Would love to see if that measured up the same way in Thrift. > > 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. >> > > The JVM already has this. You can do Integer.valueOf to get the cached > version of the boxed value. > > On the whole this seems like it would amount to a pretty moderate amount of > code generation changes. As I've said previously, I'm pro performance > improvements, but unless I see a specific benchmark that indicates this is > killing us, for the moment I would say just open a JIRA ticket and we'll get > around to it eventually. Of course, you are free to submit a patch if you > have the time and inclination :) > > -Bryan >
