[jira] [Resolved] (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:all-tabpanel ]

Jukka Zitting resolved OAK-855.
-------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 0.12)
                   0.11

Yes, for the most part this is already done.

I think the above case in {{setRoot()}} for the {{KernelNodeStore}} still exists. But I believe the MongoNS effort makes it easier to avoid that {{equals}} call, so  it's probably best to leave the {{KernelNodeStore}} as-is for now.

Thus resolving this as Fixed. We can follow up on any remaining cases in more specific issues.

> 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
>             Fix For: 0.11
>
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)