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 "Antonio Sanso (JIRA)" <ji...@apache.org> on 2013/05/23 14:27:29 UTC
[jira] [Updated] (OAK-839) Optimization in the Node#getNodes
[ https://issues.apache.org/jira/browse/OAK-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Sanso updated OAK-839:
------------------------------
Attachment: GetNodesTest.java
attaching test case
> 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
>
>
> 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