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 "Jukka Zitting (JIRA)" <ji...@apache.org> on 2014/06/02 17:24:01 UTC

[jira] [Commented] (OAK-1866) SegmentMK: Inefficient flat node comparisons

    [ https://issues.apache.org/jira/browse/OAK-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14015460#comment-14015460 ] 

Jukka Zitting commented on OAK-1866:
------------------------------------

Merged to the 1.0 branch for 1.0.1 in revision 1599239.

> SegmentMK: Inefficient flat node comparisons
> --------------------------------------------
>
>                 Key: OAK-1866
>                 URL: https://issues.apache.org/jira/browse/OAK-1866
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, segmentmk
>    Affects Versions: 1.0
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>              Labels: performance
>             Fix For: 1.0.1, 1.1
>
>
> The SegmentMK has an optimization for the common case where only a single child node among many has been updated. For the most part this code works very well, but there's one code path where this optimization is currently not applied and as a result a node comparison ends up traversing the full list of child nodes.
> The troublesome code path gets triggered when a single child node is updated in one commit and then another commit does some more complex changes (adds or removes a node and/or modifies more than a single node). 
> Usually this isn't too big an issue since traversing even thousands of child node entries is very fast with the SegmentMK, but things slow down a lot when there are millions of children. Unfortunately that is exactly what happens with the UUID index in a large repository with millions of referenceable nodes...



--
This message was sent by Atlassian JIRA
(v6.2#6252)