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

["Thomas Mueller (JIRA)" <ji...@apache.org>]

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

Thomas Mueller edited comment on OAK-839 at 5/23/13 2:15 PM:
-------------------------------------------------------------

> determine the root cause for getChildNodeCount being slow

I'm not sure what you mean with "slow". If you mean "O( n ) and not O(1)", then the obvious answer is: access right checks. But it's potentially slow even for an admin user if the storage backend (MicroKernel or not) doesn't store the count. And even if the storage backend does store the count, Oak can't use it because some children could be hidden (start with ":"). I don't see a way to make getChildNodeCount an O(1) operation, given the features we want to support.



                
      was (Author: tmueller):
    > determine the root cause for getChildNodeCount being slow

I'm not sure what you mean with "slow". If you mean "O(n) and not O(1)", then the obvious answer is: access right checks. But it's potentially slow even for an admin user if the storage backend (MicroKernel or not) doesn't store the count. And even if the storage backend does store the count, Oak can't use it because some children could be hidden (start with ":"). I don't see a way to make getChildNodeCount an O(1) operation, given the features we want to support.



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