Noticeable Performance Issues #1

Open
zmoazeni opened this Issue Jun 18, 2012 · 10 comments

5 participants

@zmoazeni

First, thanks a ton for writing this. I really like it in combination with http://marmalade-repo.org/packages/find-file-in-project

However, I've noticed that basic Emacs ido fuzzy matches are noticeably slower.

M-x
"describe-fu" (for describe-function)
"toggle"

Compared to:

M-x
ido-better-flex/disable<RET>

M-x
"describe-fu" (for describe-function)
"toggle"

Do you have any ideas on where I could investigate performance improvements. Or at the very least only enable better flex when searching for files?

@vic
Owner

Regarding the performance issues, I believe it could be due to how the algorithm works: when it searches for a char it looks forward for it, but if the char could not be found forward from the latest matched position, the character is searched backwards, creating a kind of binary-map of what chars did matched on the string, this map is then converted to a number to get the final score. The thing is, when the candidates include large strings that could match and backtrack a lot, you could see this performance issues.

If you take a look at https://github.com/vic/ido-better-flex/blob/master/ido-better-flex.el#L103 you'll see when the algorithm is backtracking.

It would be awesome if you can get up with some idea on how we can improve this.

Regarding your question about using this package only when searching for files, the first solution that comes to my mind is you could advice your find finding function so that this advice enables better-flex just around the find-finding function.

cheers.

@zmoazeni

Awesome. Thanks for the tips!

@danskarda

I prepared several performance optimizations to both ido and ido-better-flex packages. I got speed improvements up to 20x times. I use ido-better-flex together with smex (M-x replacement) and see no delays in Emacs on my old notebook with Intel Core 2 Duo.

My optimizations are based on caching, input pre-filtering and few Emacs Lisp tricks (rather than change of ido-better-flex main algorithms).

This weekend I attend BarCamp Brno. Once I am back I will push my changes to upstream projects.

Happy Lisping

@vic
Owner

@orfelyus awesome looking forward for a pull request with those optimizations, cheers ! :)

@diasjorge

@orfelyus any chance we might see those performance optimizations? please 😄

@vic
Owner

@scottjad would you mind creating a pull request with that improvements?

@scottjad

@vic I don't actually use the improvements (or your package). I wasn't able to see a performance improvement from his changes. With M-x smex if I typed "desfun" it took between 1.5s and 2s to come up with the result on your fork and his. It didn't seem to make a difference. Granted I might have it misconfigured.

@danskarda

I am sorry for not responding for so long. Mea culpa.

For best performance you need three components:

  • ido-mode-el (patches to original ido-mode-el)
  • ido-speed-hacks
  • patched ido-better-flex

ido-speed-hack README.md file describes how to install all required components.

Major improvements are in modules ido-speed-hacks and ido-mode. Could you please execute your tests again with these packages compiled and loaded?

Please let me know the results. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment