[
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
