[
https://issues.apache.org/jira/browse/LANG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-574:
-------------------------------
Fix Version/s: 3.0
> HashCodeBuilder append(Object) could be more efficient
> ------------------------------------------------------
>
> Key: LANG-574
> URL: https://issues.apache.org/jira/browse/LANG-574
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
> Affects Versions: 2.4
> Environment: Sun JDK 1.6.0_17
> Reporter: Anthony Whitford
> Priority: Minor
> Fix For: 3.0
>
>
> See:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/java/org/apache/commons/lang3/builder/HashCodeBuilder.java?view=markup
> If you use *reflectionHashCode*, you will eventually call
> *reflectionAppend(Object)* for every field (see lines 859 to 890). There is
> a long list of _instanceOf_ checks for the various types of arrays. My
> concern is that having an array field is relatively rare, yet the code does 9
> if/else checks before computing the _hashCode_ for _one_ element. I am
> thinking that it would make a lot of sense to wrap those if/else checks for
> the various array types in an *isArray* check (see Class.isArray).
> If you look at the JDK source code for *Arrays.deepToString*, you will see
> that it checks if the class is an array before checking the various types.
> Note that since it gets the Class, it doesn't need to execute _instanceOf_
> which is likely more expensive...
> I have not done profiling, but I would not be surprised if short circuiting
> these checks could improve performance by an order of magnitude. The
> assumption is that getting the Class of an Object and asking it if it is an
> array is cheaper than asking _instanceOf_ 9 times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
