[
https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675842#comment-13675842
]
Thomas Mueller commented on OAK-855:
------------------------------------
> It could well be that the equals calls wouldn't even be needed after that.
Yes, we will have to come up with a simple test case. So far I only saw it
while running the integration test, using jps -l / jstack -l.
> A ModifiedNodeState is typically (though not always) non-equal
Yes, I have the following potential optimization in mind: if one side of the
equals is a ModifiedNodeState with base "x" and the other side is "x". In that
case, only those items would need to be compared that are modified in the
ModifiedNodeState.
> equals() method shouldn't really be needed that much
One caller is: ModifiedNodeState.compareAgainstBaseState. I think it _is_ used
a lot. Also, it is used in other places, just because it is there.
> Thus instead of focusing too much on equals() I think we'd get better results
> by looking at where and why it's being called
It's actually quite hard (for Eclipse) to list the callers because equals is
such a common method - another reason to rename the method or use another
mechanism :-)
> NodeState.equals is sometimes very slow
> ---------------------------------------
>
> Key: OAK-855
> URL: https://issues.apache.org/jira/browse/OAK-855
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Thomas Mueller
>
> The method NodeState.equals seems to be very slow sometimes, for example if a
> KernelNodeState is compared against a ModifiedNodeState. A recursive
> traversal is used in this case. I found this problem when running the
> integration tests (-PintegrationTesting). I guess it's specially a problem if
> there are many child nodes.
> I wonder if we could use a shortcut when comparing a ModifiedNodeState
> against a non-modified one: isn't by definition the ModifiedNodeState _never_
> equal to a non-modified one, unless there are no changes?
> When comparing two ModifiedNodeState objects (not sure if that's a common use
> case), then a simple optimization would also be possible.
> What's also not nice is: it seems multiple NodeState classes implement
> equals, but not hashCode. Instead of overriding the equals method, I wonder
> if we should use another mechanism.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
