[jira] [Comment Edited] (JCRVLT-789) AggregateImpl might be able to avoid iterating over sibling nodes
[
https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933889#comment-17933889
]
Julian Reschke edited comment on JCRVLT-789 at 3/10/25 1:20 PM:
So the idea is to have an alternate API on the filter that returns the set of
child node names for which the check of "isAncestor" will return true (or is
likely to...).
If we had this, we could avoid iterating through the child nodes, and just
inspect these specific child node names.
Such as:
{noformat}
List childNamesOfInterest =
filter.getChildNamesBelowParent(node.getPath());
{noformat}
where "node" is the path for which we currently get all child nodes. We could
then just iterate though these child nodes, instead of iterating through all of
of them.
Extra points for using
https://developer.adobe.com/experience-manager/reference-materials/spec/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html#getNodes(java.lang.String)
was (Author: reschke):
So the idea is to have an alternate API on the filter that returns the set of
child node names for which the check of "isAncestor" will return true.
If we had this, we could avoid iterating through the child nodes, and just
inspect these specific child node names.
Such as:
{noformat}
List childNamesOfInterest =
filter.getChildNamesBelowParent(node.getPath());
{noformat}
where "node" is the path for which we currently get all child nodes.
Extra points for using
https://developer.adobe.com/experience-manager/reference-materials/spec/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html#getNodes(java.lang.String)
> AggregateImpl might be able to avoid iterating over sibling nodes
> -
>
> Key: JCRVLT-789
> URL: https://issues.apache.org/jira/browse/JCRVLT-789
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> See
> [https://github.com/apache/jackrabbit-filevault/blob/367ffb423d84993c5bb0eb0186f810a58b6227be/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L696]
>
> This code currently iterates unconditionally over child nodes (which is a
> problem for large collections). We might be able to avoid that by checking
> the filters before descending.
> I tried a quick hack, and that made tests fail (which is good).
> Will continue with a test case first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-789) AggregateImpl might be able to avoid iterating over sibling nodes
[ https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934254#comment-17934254 ] Julian Reschke edited comment on JCRVLT-789 at 3/11/25 5:08 PM: Potential fix in [https://github.com/apache/jackrabbit-filevault/pull/362] ...feedback appreciated. EDIT: ready for review. was (Author: reschke): Potential fix in [https://github.com/apache/jackrabbit-filevault/pull/362] ...feedback appreciated. > AggregateImpl might be able to avoid iterating over sibling nodes > - > > Key: JCRVLT-789 > URL: https://issues.apache.org/jira/browse/JCRVLT-789 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > See > [https://github.com/apache/jackrabbit-filevault/blob/367ffb423d84993c5bb0eb0186f810a58b6227be/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L696] > > This code currently iterates unconditionally over child nodes (which is a > problem for large collections). We might be able to avoid that by checking > the filters before descending. > I tried a quick hack, and that made tests fail (which is good). > Will continue with a test case first. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-789) AggregateImpl might be able to avoid iterating over sibling nodes
[
https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933848#comment-17933848
]
Julian Reschke edited comment on JCRVLT-789 at 3/10/25 11:57 AM:
-
For now, we might get away by handling the prefixes
{noformat}
/\Q
\Q/
{noformat}
and the suffixes
{noformat}
\E
\E/.*
{noformat}
where "\Q...\E" is regexp-speak for "match everything in between as literal".
(This is from the example that was reported to me; not sure though whether it
represents all real-world cases).
In general - unless we find a precise way to do this - we should start with the
low hanging fruits.
was (Author: reschke):
For now, we might get away by handling the prefixes
{noformat}
/\Q
\Q/
{noformat}
and the suffixes
{noformat}
\E
\E/.*
{noformat}
where "\E...\Q" is regexp-speak for "match everything in between as literal".
(This is from the example that was reported to me; not sure though whether it
represents all real-world cases).
In general - unless we find a precise way to do this - we should start with the
low hanging fruits.
> AggregateImpl might be able to avoid iterating over sibling nodes
> -
>
> Key: JCRVLT-789
> URL: https://issues.apache.org/jira/browse/JCRVLT-789
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> See
> [https://github.com/apache/jackrabbit-filevault/blob/367ffb423d84993c5bb0eb0186f810a58b6227be/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L696]
>
> This code currently iterates unconditionally over child nodes (which is a
> problem for large collections). We might be able to avoid that by checking
> the filters before descending.
> I tried a quick hack, and that made tests fail (which is good).
> Will continue with a test case first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-789) AggregateImpl might be able to avoid iterating over sibling nodes
[
https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933782#comment-17933782
]
Julian Reschke edited comment on JCRVLT-789 at 3/10/25 11:46 AM:
-
The complicated part is to determine whether a filter path indeed requires
regexp matching - so we not only need to check whether something *is* a regexp
syntactically, but also whether the expression *needs* to be processed as
regexp.
For instance
{code}
a\.b
{code}
parses aas regexp, but would only match
{code}
a.b
{code}
was (Author: reschke):
The complicated part is to determine where a filter path indeed requires regexp
matching - so we not only need to check whether something *is* a regexp
syntactically, but also whether the expression *needs* to be processed as
regexp.
For instance
{code}
a\.b
{code}
parses aas regexp, but would only match
{code}
a.b
{code}
> AggregateImpl might be able to avoid iterating over sibling nodes
> -
>
> Key: JCRVLT-789
> URL: https://issues.apache.org/jira/browse/JCRVLT-789
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> See
> [https://github.com/apache/jackrabbit-filevault/blob/367ffb423d84993c5bb0eb0186f810a58b6227be/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L696]
>
> This code currently iterates unconditionally over child nodes (which is a
> problem for large collections). We might be able to avoid that by checking
> the filters before descending.
> I tried a quick hack, and that made tests fail (which is good).
> Will continue with a test case first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
