[
https://issues.apache.org/jira/browse/OAK-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665162#comment-13665162
]
Antonio Sanso commented on OAK-839:
-----------------------------------
bq. suggest to follow up on both fronts here: determine the root cause for
getChildNodeCount being slow, try to fix that
+1 I am already doing this in OAK-833. The readstatus calculation might help
here
bq. and try to avoid upfront calculation of the sizes for getNodes.
+1
Thanks
> 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
>
>
> 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
