Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 16 May 2016 08:25:12 +0000 (UTC)
From: "Philippe Marschall (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12969830.1463322456000.194969.1463387112940@Atlassian.JIRA>
In-Reply-To: <JIRA.12969830.1463322456000@Atlassian.JIRA>
References: <JIRA.12969830.1463322456000@Atlassian.JIRA> <JIRA.12969830.1463322456561@arcas>
Subject: [jira] [Commented] (LANG-1229) Performance regression due to cyclic
 hashCode guard
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 16 May 2016 08:25:14 -0000


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

Philippe Marschall commented on LANG-1229:
------------------------------------------

Personally I don't like boolean flags to methods that change the behaviour of methods. Personally I prefer two different methods for two different things. But if a boolean flag is an acceptable compromise then I'll take it.

> Performance regression due to cyclic hashCode guard
> ---------------------------------------------------
>
>                 Key: LANG-1229
>                 URL: https://issues.apache.org/jira/browse/LANG-1229
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.builder.*
>    Affects Versions: 3.5
>            Reporter: Philippe Marschall
>
> We observed a severe performance regression in HashCodeBuilder in 3.5 trunk compared to 3.4 release. We get about 20% of the throughput in 3.5 trunk for common cases compared to 3.4 release. Previously there was no noticeable overhead of using HashCodeBuilder. Investigating we found the performance degradation was caused by the fix for LANG-456. It causes the method to be too large to be inlined and escape analysis to fail (see LANG-1218 for a related discussion).
> We currently do not see a way to keep the 3.4 performance and support cyclic graphs. The append methods have not supported cycles for so long we feel it's de facto part of the contract by now. Since neither the JDK nor the Guava hashCode helper methods support cyclic graphs we don't believe this is an unreasonable assumption. In addition EqualsBuilder#append(Object,Object) doesn't support cycles.
> If supporting cycles is a requirement we propose the introduction of new #appendRecursive (or named differently) methods to both HashCodeBuilder and EqualsBuilder that add cycle guards. If that is an acceptable compromise we would be willing to provide patches.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)