jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCRVLT-53) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
Date Mon, 07 Jul 2014 10:05:34 GMT

    [ https://issues.apache.org/jira/browse/JCRVLT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053521#comment-14053521

Thomas Mueller commented on JCRVLT-53:

> My patch still improves performance about 20-fold (for Oak) and 10-fold (for Jackrabbit
2.x), so I think it's worth it.

Yes, in VLT, and after Jukka's improvement. Jukkas improvement is very good, but it only addresses
Oak (not Jackrabbit 2.x), and it can't possibly get to the same performance as when not calling
orderBefore at all.

I think it's also important to fix this in VLT because in the future, we expect even flatter
hierarchies. In which case trying to avoid orderBefore is even more important (my test case
is "just" 10'000 child nodes). I also expect other people will try to re-use the algorithm
from VLT for slightly different use cases (using VLT code as the "gold standard"). So it is
important that VLT uses the most optimal solution.

> vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
> ---------------------------------------------------------------------------
>                 Key: JCRVLT-53
>                 URL: https://issues.apache.org/jira/browse/JCRVLT-53
>             Project: Jackrabbit FileVault
>          Issue Type: Improvement
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>         Attachments: JCR-3793.patch, ReorderTest.java
> The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder re-orders orderable
child nodes by using Node.orderBefore. This is very slow if there are many child nodes, specially
with Oak (minutes for 10'000 nodes, while only about 1 second for Jackrabbit 2.x).
> [~tripod], I wonder if a possible solution is to first check whether re-ordering is needed?
For example using:
> {noformat}
>     boolean isOrdered(ArrayList<String> names, Node parent)
>             throws RepositoryException {
>         NodeIterator it1 = parent.getNodes();
>         for (Iterator<String> it2 = names.iterator(); it2.hasNext();) {
>             if (!it1.hasNext() || !it1.nextNode().getName().equals(it2.next())) {
>                 return false;
>             }
>         }
>         return !it1.hasNext();
>     }
> {noformat}

This message was sent by Atlassian JIRA

View raw message