| Generated Code in eGet-inefficient for primitive-integer values? [message #419488] |
Sat, 24 May 2008 14:52  |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
I'm not sure about that but I just ran findBugs and found an interesting
warning for code like this in eGet:
public Object eGet(int featureID, boolean resolve, boolean coreType) {
switch (featureID) {
// .........
case ResourcemanagerPackage.FONT__SIZE:
return new Integer(getSize());
}
}
FindBugs says the following:
--------------8<--------------
Using new Integer(int) is guaranteed to always result in a new object
whereas Integer.valueOf(int) allows caching of values to be done by the
compiler, class library, or JVM. Using of cached values avoids object
allocation and the code will be faster.
Values between -128 and 127 are guaranteed to have corresponding cached
instances and using valueOf is approximately 3.5 times faster than using
constructor. For values outside the constant range the performance of
both styles is the same.
Unless the class must be compatible with JVMs predating Java 1.5, use
either autoboxing or the valueOf() method when creating instances of
Long, Integer, Short, Character, and Byte.
--------------8<--------------
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Generated Code in eGet-inefficient for primitive-integer values? [message #419489 is a reply to message #419488] |
Sat, 24 May 2008 15:05  |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Tom,
That's a good point. When generating for 5.0 compliance, we should just
allow the language to do the autoboxing which will take advantage of the
cached instances. Please open a bugzilla enhancement request and we'll
address this in the 2.5 stream.
Tom Schindl wrote:
> Hi,
>
> I'm not sure about that but I just ran findBugs and found an
> interesting warning for code like this in eGet:
>
> public Object eGet(int featureID, boolean resolve, boolean coreType) {
> switch (featureID) {
> // .........
> case ResourcemanagerPackage.FONT__SIZE:
> return new Integer(getSize());
> }
> }
>
>
> FindBugs says the following:
> --------------8<--------------
> Using new Integer(int) is guaranteed to always result in a new object
> whereas Integer.valueOf(int) allows caching of values to be done by
> the compiler, class library, or JVM. Using of cached values avoids
> object allocation and the code will be faster.
>
> Values between -128 and 127 are guaranteed to have corresponding
> cached instances and using valueOf is approximately 3.5 times faster
> than using constructor. For values outside the constant range the
> performance of both styles is the same.
>
> Unless the class must be compatible with JVMs predating Java 1.5, use
> either autoboxing or the valueOf() method when creating instances of
> Long, Integer, Short, Character, and Byte.
> --------------8<--------------
>
> Tom
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generated Code in eGet-inefficient for primitive-integer values? [message #419503 is a reply to message #419489] |
Sun, 25 May 2008 11:45 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
For all interested parties the bug is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233813
Tom
Ed Merks schrieb:
> Tom,
>
> That's a good point. When generating for 5.0 compliance, we should just
> allow the language to do the autoboxing which will take advantage of the
> cached instances. Please open a bugzilla enhancement request and we'll
> address this in the 2.5 stream.
>
>
> Tom Schindl wrote:
>> Hi,
>>
>> I'm not sure about that but I just ran findBugs and found an
>> interesting warning for code like this in eGet:
>>
>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>> switch (featureID) {
>> // .........
>> case ResourcemanagerPackage.FONT__SIZE:
>> return new Integer(getSize());
>> }
>> }
>>
>>
>> FindBugs says the following:
>> --------------8<--------------
>> Using new Integer(int) is guaranteed to always result in a new object
>> whereas Integer.valueOf(int) allows caching of values to be done by
>> the compiler, class library, or JVM. Using of cached values avoids
>> object allocation and the code will be faster.
>>
>> Values between -128 and 127 are guaranteed to have corresponding
>> cached instances and using valueOf is approximately 3.5 times faster
>> than using constructor. For values outside the constant range the
>> performance of both styles is the same.
>>
>> Unless the class must be compatible with JVMs predating Java 1.5, use
>> either autoboxing or the valueOf() method when creating instances of
>> Long, Integer, Short, Character, and Byte.
>> --------------8<--------------
>>
>> Tom
>>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
Powered by
FUDForum. Page generated in 0.03221 seconds
] 
Search
Help
Register
Login
Home
