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