thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane <>
Subject Re: Autoboxing in generated java code
Date Thu, 16 Jul 2009 00:08:28 GMT
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.


On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <> 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 :
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message