[jira] [Comment Edited] (OAK-855) NodeState.equals is sometimes very slow

["Jukka Zitting (JIRA)" <ji...@apache.org>]

    [ 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