flx-rs with high candidate count becomes slower for repeated calls to flx-score #3
Comments
|
I cannot produce this issue (dotimes (x 1000)
(measure-time
(flx-rs-score "switch-to-buffer" "s-t-b")))I got I don't think the high candidate count would add up anything. My best guess is the |
|
Got it, you're right. flx-rs-score is struggling to keep up with really long strings, e.g. Once I early exit like this, my history function becomes fairly fast again, |
|
@jcs090218 I wonder how much of a performance boost we'd get in practical scenarios with a cache. I'm thinking collections that start getting big will have a noticeable effect at some point. Of course, this is a flawed example, considering the cache will be hit every time in this case but does show that there might be possible performance improvements. I'm guessing around 4000 candidates as it is right now will keep the same 'this is very fast' typing feeling (since completing-read is synchronous) and any more will slowly create a 'there's noticeable latency on every keystroke' feeling. This might be ignoring the fact that the initial abc* filtering on a collection that big may be more/same as the flx scoring itself. |
|
By seeing their document https://github.com/lewang/flx#memory-usage. I don't think the cache is needed for flx-rs since it's a lot faster (16 times faster on my machine; I'm using Windows). Cache seems to be useless since your fuzzy matching will likely always be different. But as their document mentioned, it will still be faster than flx-rs since it will return an O(1) time after the first fuzzy search. PR are welcome if you would like to give it a try. Some links might be helpful:
|
|
I think I didn't really make a point in my previous post. In conclusion, I think with that much of speed up, without the cache is reasonable but nice to have. |
|
I think the cache will be super useful for repeated searches, e.g. completing-reada| [collection 1] same completing-read session or completing read session 2a| [cached collection 1] and maybe an extension to the original flx with a file cache that can warm start the flx cache. e.g. Restart emacs: completing read session 3a| [cached collection 1] I may find the time to both learn rust & implement this though (was hoping our rust expert could do it ;)). Do you remember quick locations where you changed the implementation (e.g. spots that were using cache that now aren't). Otherwise I may have to do an entire file diff to figure out where to implement this cache. |
|
Yeah, I think cache could be one of the missing feature from But to answer your question, the entry point is at jcs090218/flx-rs/src/search.rs#L328. Once you are done with the cache implementation, you can change function: Line 55 in 9af1aee with the cache parameter at the end. The documentation from
This is one of the main reason why I haven't start working on cache. I reckon the job isn't easy, and the result can be testable. Another issue if the HashMap/ |
I was thinking, at first, we don't expose the cache to the elisp machinery and use an internal cache instead. I cooked a little up from digging through the flx code but my rust skills aren't up to par I think. The clone/copy/borrow semantics are tripping me up and I'm not sure how to easily declare a static variable to use in these functions. |
|
@jojojames Hi, Do you want to move this to another issue then maybe we can discuss over there? So I don't get confused with the title. :) |
|
Let's move the discussion to the rust implementation repo, see the-flx/flx-rs#4. |
|
Sounds good, done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the configuration/completion-style defined here: lewang/flx#54 (comment)
and then using a homegrown zsh-history completing-read function like this:
If I log the time it takes for flx-rs-score to run, like so:
Logs printed begins to look like this:
If I use the regular flx:
The text was updated successfully, but these errors were encountered: