| Primitive boxing [message #764299] |
Sun, 11 December 2011 16:59  |
Eclipse User |
|
|
|
Hi,
I'm working on a project using xtext to create a language, and we noticed that xtext always boxes primitives as their wrapper classes, and uses extension methods to perform even basic arithmetic:
IntegerExtensions.operator_plus(((Integer)_value_1), ((Integer)1))
We have some situations where we know that we're going to be using particular binary operations for ints a great deal, and my supervisor is concerned that we may incur a performance hit by boxing them like this all the time.
Is this something that has been looked into by anyone else? Or is the assumption that JIT will just sort all of that kind of thing out and fix any potential performance issues?
I'm looking into doing some benchmarking for this, but I'd love to hear whether anyone else has looked into this.
Also: is there an easy way to change this behavior for particular circumstances? Our situation has a very large number of increments and comparisons (<, <= etc.) that we're concerned about: can we override the default boxing behavior to use the primitive operators?
Thanks,
Jeff
|
|
|
| Re: Primitive boxing [message #764447 is a reply to message #764299] |
Mon, 12 December 2011 02:40  |
| Eclipse User |
|
|
|
Hi Jeff,
we changed that in the latest release and offer overloaded variants with
primitive types.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 11.12.11 22:59, schrieb Jeff:
> Hi,
> I'm working on a project using xtext to create a language, and we
> noticed that xtext always boxes primitives as their wrapper classes, and
> uses extension methods to perform even basic arithmetic:
>
> IntegerExtensions.operator_plus(((Integer)_value_1), ((Integer)1))
>
> We have some situations where we know that we're going to be using
> particular binary operations for ints a great deal, and my supervisor is
> concerned that we may incur a performance hit by boxing them like this
> all the time.
> Is this something that has been looked into by anyone else? Or is the
> assumption that JIT will just sort all of that kind of thing out and fix
> any potential performance issues?
>
> I'm looking into doing some benchmarking for this, but I'd love to hear
> whether anyone else has looked into this.
>
> Also: is there an easy way to change this behavior for particular
> circumstances? Our situation has a very large number of increments and
> comparisons (<, <= etc.) that we're concerned about: can we override the
> default boxing behavior to use the primitive operators?
>
> Thanks,
> Jeff
|
|
|
|
Powered by
FUDForum. Page generated in 0.05403 seconds
Home