[
https://issues.apache.org/jira/browse/OAK-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Sanso updated OAK-839:
------------------------------
Attachment: OAK-839-patch.txt
attaching new patch that calculate the {{RangeIteratorAdaper}} size only on
demand
> 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
