You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Stephane <sl...@gmail.com> on 2009/07/15 23:02:15 UTC
Autoboxing in generated java code
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
Re: Autoboxing in generated java code
Posted by Stephane <sl...@gmail.com>.
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 <br...@rapleaf.com> 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
>
Re: Autoboxing in generated java code
Posted by David Reiss <dr...@facebook.com>.
>> I don't see why manually allocating the object yourself (instead of having
>> the JVM do it) would be any faster (especially if the JVM caches frequently
>> boxed values), but maybe I'm missing something?
That's what I was thinking.
> Since even the Sun docs was mentioning
> that autoboxing has some cost, I was curious to see if it was
> something that was done by design in Thrift or not.
My guess is that they were comparing autoboxing with no boxing at all,
not autoboxing with manual boxing. I don't think we do boxing in any
place where it is not necessary (for Java).
--David
Re: Autoboxing in generated java code
Posted by Stephane <sl...@gmail.com>.
I came across the autoboxing in the java generated code using my default
Eclipse settings. By default my projects are set to mark autoboxing as an
error. As indicated I did not -yet- do any benchmark. Switching my settings
to warning instead of error, my test project build and works fine. Since
even the Sun docs was mentioning
that autoboxing has some cost, I was curious to see if it was
something that was done by design in Thrift or not.
Stéphane
On Wed, Jul 15, 2009 at 5:22 PM, Joel Meyer <jo...@gmail.com> wrote:
> On Wed, Jul 15, 2009 at 5:09 PM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > That last answer in the comment chain just asserts that this is the cost
> of
> > autoboxing. It doesn't actually describe any measurements.
> >
> > I think that is a made-up number. I find it very hard to imagine that it
> > costs hundreds of microseconds to box or unbox an integer (0.5 s / 2000).
>
>
> I would imagine that the cost of boxing a primitive value is roughly
> equivalent to the time it takes to allocate and initialize its Object
> equivalent. The cost of unboxing should be roughly equal to the time of a
> method invocation (myObject.getPrimitiveValue()).
>
> I don't see why manually allocating the object yourself (instead of having
> the JVM do it) would be any faster (especially if the JVM caches frequently
> boxed values), but maybe I'm missing something?
>
>
> >
> >
> > On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <br...@rapleaf.com>
> wrote:
> >
> > > 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.
> >
> >
> >
> >
> > --
> > Ted Dunning, CTO
> > DeepDyve
> >
> > 111 West Evelyn Ave. Ste. 202
> > Sunnyvale, CA 94086
> > http://www.deepdyve.com
> > 858-414-0013 (m)
> > 408-773-0220 (fax)
> >
>
Re: Autoboxing in generated java code
Posted by Joel Meyer <jo...@gmail.com>.
On Wed, Jul 15, 2009 at 5:09 PM, Ted Dunning <te...@gmail.com> wrote:
> That last answer in the comment chain just asserts that this is the cost of
> autoboxing. It doesn't actually describe any measurements.
>
> I think that is a made-up number. I find it very hard to imagine that it
> costs hundreds of microseconds to box or unbox an integer (0.5 s / 2000).
I would imagine that the cost of boxing a primitive value is roughly
equivalent to the time it takes to allocate and initialize its Object
equivalent. The cost of unboxing should be roughly equal to the time of a
method invocation (myObject.getPrimitiveValue()).
I don't see why manually allocating the object yourself (instead of having
the JVM do it) would be any faster (especially if the JVM caches frequently
boxed values), but maybe I'm missing something?
>
>
> On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
>
> > 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.
>
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>
> 111 West Evelyn Ave. Ste. 202
> Sunnyvale, CA 94086
> http://www.deepdyve.com
> 858-414-0013 (m)
> 408-773-0220 (fax)
>
Re: Autoboxing in generated java code
Posted by Ted Dunning <te...@gmail.com>.
Thanks for that.
On Wed, Jul 15, 2009 at 8:26 PM, Jonathan Marcus <ja...@jobstick.com>wrote:
> Math check: it's not 0.5s/2000, it's 0.5ms/2000, which is around a quarter
> of a microsecond, which seems plausible
>
Re: Autoboxing in generated java code
Posted by Jonathan Marcus <ja...@jobstick.com>.
Math check: it's not 0.5s/2000, it's 0.5ms/2000, which is around a
quarter of a microsecond, which seems plausible
It also doesn't sound like a huge performance hit: you can do 4,000,000
of them in a second, which seems pretty small compared to the overall
overhead of Thrift (not to mention any business logic).
--Jonathan
Ted Dunning wrote:
> That last answer in the comment chain just asserts that this is the cost of
> autoboxing. It doesn't actually describe any measurements.
>
> I think that is a made-up number. I find it very hard to imagine that it
> costs hundreds of microseconds to box or unbox an integer (0.5 s / 2000).
>
> On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
>
>
>> 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.
>>
>
>
>
>
>
Re: Autoboxing in generated java code
Posted by Ted Dunning <te...@gmail.com>.
That last answer in the comment chain just asserts that this is the cost of
autoboxing. It doesn't actually describe any measurements.
I think that is a made-up number. I find it very hard to imagine that it
costs hundreds of microseconds to box or unbox an integer (0.5 s / 2000).
On Wed, Jul 15, 2009 at 4:51 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> 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.
--
Ted Dunning, CTO
DeepDyve
111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
http://www.deepdyve.com
858-414-0013 (m)
408-773-0220 (fax)
Re: Autoboxing in generated java code
Posted by Bryan Duxbury <br...@rapleaf.com>.
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
Re: Autoboxing in generated java code
Posted by Stephane <sl...@gmail.com>.
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 <br...@rapleaf.com> 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
>>
>
>
Re: Autoboxing in generated java code
Posted by Bryan Duxbury <br...@rapleaf.com>.
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