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

Reply via email to