[
https://issues.apache.org/jira/browse/JCRVLT-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905983#comment-17905983
]
Julian Reschke commented on JCRVLT-789:
---------------------------------------
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)
