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

Julian Reschke edited comment on JCRVLT-789 at 12/16/24 10:39 AM:
------------------------------------------------------------------

Potential IT:

bq. I think it's as simple as -
bq. 
bq.     Create any node with a large number of siblings (doesn't need to be an 
asset)
bq.         lets say /var/test/00000 to /var/test/99999
bq.     Create a package with a filter with the path of 1 of these nodes
bq.         ie /var/test/12345
bq.     Build the package
bq. 
bq. IIUC the code at [1] will read all 100,000 siblings (the node being 
targeted and the other 99,999) when really this is unnecessary in this case.



(ack Tom Blackford)




was (Author: reschke):
Potential IT:

bq. I think it's as simple as -
bq. 
bq.     Create any node with a large number of siblings (doesn't need to be an 
asset)
bq.         lets say /var/test/00000 to /var/test/99999
bq.     Create a package with a filter with the path of 1 of these nodes
bq.         ie /var/test/12345
bq.     Build the package
bq. 
bq. IIUC the code at [1] will read all 100,000 siblings (the node being 
targeted and the other 99,999) when really this is unnecessary in this case.
bq. 
bq.     Q: do we see the same problem both on segmentmk and documentmk?


(ack Tom Blackford)



> AggregateImpl might be able to avoid iterating over child nodes
> ---------------------------------------------------------------
>
>                 Key: JCRVLT-789
>                 URL: https://issues.apache.org/jira/browse/JCRVLT-789
>             Project: Jackrabbit FileVault
>          Issue Type: Improvement
>          Components: vlt
>            Reporter: 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)

Reply via email to