You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/11/11 17:16:18 UTC
[jira] [Commented] (OAK-855) NodeState.equals is sometimes very
slow
[ https://issues.apache.org/jira/browse/OAK-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13819078#comment-13819078 ]
angela commented on OAK-855:
----------------------------
is this still an issue? afaik there has been a lot of modifications in that area that may have addressed this issue...
> 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.12
>
>
> 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)