[
https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675866#comment-13675866
]
Jukka Zitting edited comment on OAK-855 at 6/5/13 1:09 PM:
-----------------------------------------------------------
bq. One caller is: ModifiedNodeState.compareAgainstBaseState. I think it is
used a lot.
Right, I remember adding that one. The reason for that {{equals()}} call is the
strict definition of {{NodeStateDiff.childNodeChanged()}}, i.e. that the method
will be called when that subtree contains changes. In {{ModifiedNodeState}}
that's likely, but since it's not certain we need to first check for equality.
A potentially better alternative could be to relax the {{childNodeChanged()}}
definition so that it could also be called when there actually aren't any
changes in the given subtree. As long as that happens seldom enough, the extra
processing overhead should be negligible and we could avoid the current
{{equals()}} call in {{ModifiedNodeState.compareAgainstBaseState()}}.
was (Author: jukkaz):
bq. One caller is: ModifiedNodeState.compareAgainstBaseState. I think it is
used a lot.
Right, I remember adding that one. The reason for that {{equals()}} call is the
strict definition of {{NodeStateDiff.childNodeChanged()}, i.e. that the method
will be called when that subtree contains changes. In {{ModifiedNodeState}}
that's likely, but since it's not certain we need to first check for equality.
A potentially better alternative could be to relax the {{childNodeChanged()}}
definition so that it could also be called when there actually aren't any
changes in the given subtree. As long as that happens seldom enough, the extra
processing overhead should be negligible and we could avoid the current
{{equals()}} call in {{ModifiedNodeState.compareAgainstBaseState()}}.
> 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
