[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048847#comment-14048847
]
Thomas Mueller commented on JCR-3793:
-------------------------------------
[~jukkaz], yes I have a potential patch for Oak, which is: only update the
"ordered" list in case the order is actually different. And in fact the order
is not different, however Oak is still very slow.
With the vlt patch, performance improved even for Jackrabbit 2.x (from about 1
second to 0.1 seconds), as well as for Oak (to around 0.1 seconds).
I don't have a _good_ benchmark, but I will upload the benchmark I have.
> vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
> ---------------------------------------------------------------------------
>
> Key: JCR-3793
> URL: https://issues.apache.org/jira/browse/JCR-3793
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Reporter: Thomas Mueller
> Attachments: JCR-3793.patch
>
>
> 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
(v6.2#6252)
