-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Small performance regression in ignore-0.4.x #835
Comments
This seems to be caused by the additional (apparently, the gitignore matchers are fully constructed even though no ignore-matching is performed) |
@sharkdp What corpus were your tests above on? I finally had a chance to look at this, and I can't really reproduce your results. I'm testing on the chromium repo:
Testing ripgrep on current master:
Testing ripgrep with this PR, rebased on current master:
|
I was running this on my home folder - not very helpful, I'm sorry. Two things seem to be different in your case:
I know it's not a very scientific method, but could you try to run the following commands in your home folder (or some other large directory)? I was just re-running the benchmarks with the rebased branch (which is now included in #836), and I still see a 10% speedup:
|
This commit makes Gitignore::empty a bit faster by avoiding allocation and manually specializing the implementation instead of routing it through the GitignoreBuilder. This helps improve uses of ripgrep that traverse *many* directories, and in particular, when the use of ignores is disabled via command line switches. Fixes #835, Closes #836
This commit makes Gitignore::empty a bit faster by avoiding allocation and manually specializing the implementation instead of routing it through the GitignoreBuilder. This helps improve uses of ripgrep that traverse *many* directories, and in particular, when the use of ignores is disabled via command line switches. Fixes #835, Closes #836
What operating system are you using ripgrep on?
Arch Linux, x86_64
Describe your question, feature request, or bug.
I was running some benchmarks for
fd
and noticed that there was a small (~5%) performance regression when I updated fromignore-0.2.2
toignore-0.4.x
. I investigated some more and ran the same benchmark (fd -uu '[0-9]\.jpg$'
in my home folder) multiple times while changing the version of the ignore crate:There are two things to notice:
ignore-0.3.0
is not visisble because it's so fast (137 ms). This is due to a bug where not all results are shown (I didn't investigate further, but the git log seems to indicate that something was wrong withignore-0.3.0
).-uu
is the same as in ripgrep).What are the steps to reproduce the behavior?
I can reproduce this behavior with ripgrep itself:
(benchmarks performed with hyperfine on a warm disk cache)
Again, the difference is small (~4%) but significant.
The text was updated successfully, but these errors were encountered: