Clarification and motivation
Thanks to the recent profiling performed by @aeqz, I noted the that matchesGlobPatterns takes so much time. And hilariously, looks like we somehow fell into that very problem - we compile glob patterns every time we want to perform a match instead of compiling once in advance.
I would try to concentrate on removing matchesGlobPatterns (it joins glob compilation with matching which feels like an anti-pattern), compiling globs early, and carrying around the compiled globs.
Note, that matchesGlobPattern call inside toScan is shown to take 32.37% of the time at that flamegraph. But this call constitutes that minority of our logic that is not parallelized, so the gain measured in time will be larger, would not be surprised if it eventually takes half of the time.
Acceptance criteria
matchesGlobPatterns is removed.
- Every glob pattern we receive is compiled only once, or maximum twice (if necessary to parse w/ and w/o root known).
Clarification and motivation
Thanks to the recent profiling performed by @aeqz, I noted the that
matchesGlobPatternstakes so much time. And hilariously, looks like we somehow fell into that very problem - we compile glob patterns every time we want to perform a match instead of compiling once in advance.I would try to concentrate on removing
matchesGlobPatterns(it joins glob compilation with matching which feels like an anti-pattern), compiling globs early, and carrying around the compiled globs.Note, that
matchesGlobPatterncall insidetoScanis shown to take 32.37% of the time at that flamegraph. But this call constitutes that minority of our logic that is not parallelized, so the gain measured in time will be larger, would not be surprised if it eventually takes half of the time.Acceptance criteria
matchesGlobPatternsis removed.