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

Stefan Egli commented on OAK-5186:
----------------------------------

marked as critical as performance of 
[ChangeSetFilterImpl.doExcludes|https://github.com/apache/jackrabbit-oak/blob/33277f9806a3b85e0c1ef77f0abc152e1d72af0c/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/filter/ChangeSetFilterImpl.java#L170]
 directly influence commit performance.

> ChangeSetFIlterImpl: support many includePaths by filtering for 1st path name
> -----------------------------------------------------------------------------
>
>                 Key: OAK-5186
>                 URL: https://issues.apache.org/jira/browse/OAK-5186
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.5.14
>            Reporter: Stefan Egli
>            Priority: Critical
>             Fix For: 1.6
>
>         Attachments: OAK-5186.patch
>
>
> When there is a large number of include paths in the ChangeSetFilterImpl and 
> combine that with a large-ish ChangeSet (many paths) then the comparison 
> becomes expensive, as there is a loop with each ChangeSet-path, then looping 
> through each include path. Basically an {{O(n*m)}}.
> A probably ideal solution would be to implement a tree with the tree items be 
> the path elements. And have two sets of trees: the filter one and the 
> ChangeSet one.
> A simpler and perhaps 'good enough' solution could be to just look at the 
> first level name of both the filter include paths: if a ChangeSet path's 
> first level name is not in that set, then it can't be included. That would 
> allow to skip the pattern comparison (which is slower even though it is a 
> compiled {{Pattern}}).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to