[jira] [Commented] (WICKET-6977) hashCode computations generate excessive garbage objects

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17529138#comment-17529138 ] 

ASF GitHub Bot commented on WICKET-6977:
----------------------------------------

astange1 commented on PR #513:
URL: https://github.com/apache/wicket/pull/513#issuecomment-1111619239

   I'm sorry for the delay.   I got a little busy with some other obligations.   I believe I have added comments to all the impacted hashCode methods.
   
   I believe this work is now complete.   Please let me know if I missed something or if there is some other addition needed for this change.




> hashCode computations generate excessive garbage objects
> --------------------------------------------------------
>
>                 Key: WICKET-6977
>                 URL: https://issues.apache.org/jira/browse/WICKET-6977
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-core
>    Affects Versions: 9.9.0
>         Environment: Linux, JDK18
>            Reporter: Alan Stange
>            Priority: Minor
>
> We observed excessive GC pressure on Wicket servers with complex component hierarchies.   Using profilers and some code inspection, we noticed an anti-pattern being used in the hashCode computations for some classes.    The slow code was first observed in AbstractJavaScriptReferenceHeaderItem, and then in related CSS classes as well.
> The common pattern in use was similar to
> {noformat}
> int hashcode = Objects.hash(ob1, obj2, ... objn){noformat}
> which works by creating a Object[] array of size n, copying the object references into it and then calling the varargs hash() method.   In some cases, an intermediate computation was also being autoboxed, using still more memory.
> This code can be replaced with calls like
>  
> {noformat}
> int result = obj1.hashCode();
> result = 31 * result + obj2.hashCode()
> result = 31 * result + obj3.hashCode;
> return result;
> {noformat}
> which is several times faster and does not generate any garbage objects.
> The impact is large when a containing map is resized for larger component hierarchies, resulting in repeated hashcode re-computations.
> A pull request was submitted with proposed changes to the code for this issue: [link #513|https://github.com/apache/wicket/pull/513]
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)