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/02/11 22:35:23 UTC

[jira] [Commented] (OAK-1416) Adding many siblings does not scale linearly in the number of added nodes

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

Jukka Zitting commented on OAK-1416:
------------------------------------

The SegmentMK uses a HAMT data structure for child nodes, with {{O\(log n)}} insertion times. And since the transient space gets periodically purged, instead of one large insert that could be optimized to {{O\(n)}}, the performance of this benchmark operation necessarily ends up being {{O\(n log n)}}. I don't think it's reasonable to expect linear performance for this use case.

> Adding many siblings does not scale linearly in the number of added nodes
> -------------------------------------------------------------------------
>
>                 Key: OAK-1416
>                 URL: https://issues.apache.org/jira/browse/OAK-1416
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: mongomk, segmentmk
>            Reporter: Michael Dürig
>
> {{org.apache.jackrabbit.oak.jcr.LargeOperationIT#manySiblings}} does not scale linearly. Neither on a segment nor on a document node store:
> {code}
> seg quotients: 0.4181951174217804, 0.4163634468727202, 0.8406068389090829, 1.0735629207664423, 1.290574274619522
> doc quotients: 1.5713552072927073, 0.6562667320967186, 0.6101785222342979, 2.0164792911151244, 1.6989089236000476
> {code}
> In both cases adding sibling becomes more expensive when there are already many siblings. Although the behaviour is more expressed on a document node store.  See also OAK-1413 on how to read these numbers. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)