[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048844#comment-14048844
]
Jukka Zitting commented on JCR-3793:
Do we have a good benchmark for this operation. It doesn't sound as if this
should be particularly slow on Oak, so there could simply be a bug or a missing
optimization that we need to apply instead of modifying vlt.
> 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
>
> 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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048852#comment-14048852
]
Thomas Mueller commented on JCR-3793:
-
Potential patch for Oak (doesn't help much unfortunately):
{noformat}
### Eclipse Workspace Patch 1.0
#P oak-core
Index: src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
===
--- src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
(revision 1604905)
+++ src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java
(working copy)
@@ -249,6 +249,23 @@
if (name == null) {
names.add(this.name);
}
+PropertyState old = parent.nodeBuilder.getProperty(OAK_CHILD_ORDER);
+boolean isChanged;
+if (old.count() != names.size()) {
+isChanged = true;
+} else {
+isChanged = false;
+for (int i = 0; i < old.count(); i++) {
+String oldName = old.getValue(Type.STRING, i);
+if (!oldName.equals(names.get(i))) {
+isChanged = true;
+break;
+}
+}
+}
+if (!isChanged) {
+return false;
+}
parent.nodeBuilder.setProperty(OAK_CHILD_ORDER, names, NAMES);
root.updated();
return true;
{noformat}
> 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, 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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048973#comment-14048973
]
Jukka Zitting commented on JCR-3793:
It looks like we could actually optimize Oak for this case. See OAK-1934.
> 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, 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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049142#comment-14049142
]
Jukka Zitting commented on JCR-3793:
I was able to drop the "reordered" time from 99306 ms to 1965 ms in OAK-1934.
> 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, 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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050740#comment-14050740
]
Tobias Bocanegra commented on JCR-3793:
---
Of course we can optimize the clients to do only the ordering if needed. but
the algorithm in NodeNameList does "restore" the order by ordering the nodes
from back to front. if the list is already in the correct order, it should be a
no-op. So I don't see that there should be a performance difference if the
client first checks the order or if Oak does it.
btw: the API could benefit of a {{Node.setChildNodeOrder(String[] names)}}
method for such cases.
> 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, 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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051422#comment-14051422
]
Thomas Mueller commented on JCR-3793:
-
My patch still improves performance about 20-fold (for Oak) and 10-fold (for
Jackrabbit 2.x), so I think it's worth it. Unless anybody objects, I will
commit the change.
> 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
>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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051514#comment-14051514
]
Jukka Zitting commented on JCR-3793:
bq. My patch still improves performance about 20-fold (for Oak) and 10-fold
(for Jackrabbit 2.x), so I think it's worth it.
+1
> 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
>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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
[jira] [Commented] (JCR-3793) vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
[
https://issues.apache.org/jira/browse/JCR-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051765#comment-14051765
]
Tobias Bocanegra commented on JCR-3793:
---
bq. My patch still improves performance about 20-fold (for Oak) and 10-fold
(for Jackrabbit 2.x), so I think it's worth it.
In vlt? even after jukka's improvements?
> 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
>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 names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator 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)
