-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Fast extension matching #87
Conversation
…e sensitivity handling
By using a trie, we can match suffixes in linear time in the length of the *suffix itself*, rather than the length of the *list of suffixes*.
woah 😃, this is much better! |
So it looks like this is about a 4% single-threaded perf win for
With multiple threads it's neutral, I guess suffix matching is off the critical path:
|
The win is more significant for larger
|
Thank you very much, this looks great. Doing an "integration" benchmark on I imagine one benchmark would measure how long it takes to initialize a I'm not saying that you should do this, I just think it would give us a clearer picture of the situation. Performance work on this crate is extremely valuable. Initialization time has a direct impact on the startup time of many CLI programs. And the time to match a given path is crucial in programs like |
Yeah some microbenchmarks would be nice. I'm a little busy right now though, but I can keep that on the back burner unless you get to it first! |
I say "fast" but I didn't actually benchmark it yet.Benchmarks below. It's definitely better from a time complexity perspective.This is basically how I do it in
bfs
, except I used aho-corasick rather than write my own trie implementation.Includes #86.