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 2013/05/28 14:44:19 UTC

[jira] [Resolved] (OAK-839) Optimization in the Node#getNodes

     [ https://issues.apache.org/jira/browse/OAK-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved OAK-839.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 0.9
         Assignee: Jukka Zitting

Committed an adapted version of the latest patch in revision . Thanks, Antonio!

As mentioned by Thomas above, there's no simple way for us to make getting the child node count an O(1) operation (which we assumed it to be when first writing this piece of code), so lazy loading is indeed probably the right approach here.
                
> Optimization in the Node#getNodes
> ---------------------------------
>
>                 Key: OAK-839
>                 URL: https://issues.apache.org/jira/browse/OAK-839
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: jcr
>            Reporter: Antonio Sanso
>            Assignee: Jukka Zitting
>             Fix For: 0.9
>
>         Attachments: GetNodesTest.java, OAK-839-patch, OAK-839-patch.txt
>
>
> I have done some simple test with Node#getNodes and it seems that is really slow (specially compared with the Jackrabbit case).
> My test is really simple. (see as well attached GetNodesTest).
> I create a node with 10000 children and do 
> NodeIterator iterator = reader.getNode("/a").getNodes();
> The performance test shows a huge regression if compared with Jackrabbit
> * Jackrabbit
> Apache Jackrabbit Oak 0.9-SNAPSHOT
> # ReadStatusTestSingleACL        min     10%     50%     90%     max       N
> Jackrabbit                         0       0       0       1      10   33592
> * Oak
> Apache Jackrabbit Oak 0.9-SNAPSHOT
> # ReadStatusTestSingleACL        min     10%     50%     90%     max       N
> Oak-Memory                       123     125     128     144     168     115
> Me and [~tmueller] were able to find the cause of the sloweness.
> It seems that the o.a.j.oak.jcr.delegate.NodeDelegate and o.a.j.oak.jcr.NodeImpl are calling getChildrenCount that seems to be an expensive operation (and not really needed in this case).
> Patch to follow

--
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