Skip to content
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

Start sorting only after n typed chars #78

Open
r39ex opened this issue Nov 26, 2020 · 1 comment
Open

Start sorting only after n typed chars #78

r39ex opened this issue Nov 26, 2020 · 1 comment

Comments

@r39ex
Copy link

r39ex commented Nov 26, 2020

Filtering seems speedy; sorting seems kind of slow (at least on my crappy laptop). Waiting 1.5 (edit: 2.5) seconds for M-x is not an ideal user experience :/

It's probably a dumb suggestion, but what about waiting for a few keystrokes to limit the list before sorting (apart from recent items, obviously), or would that have to be implemented on the Ivy side? (edit: or company or what have you)

@raxod502
Copy link
Member

raxod502 commented Dec 3, 2020

Well, the problem is the "apart from recent items" part. We do all the sorting at once, and it's pretty well optimized. I'm not sure it would be much faster to sort only based on recency. In fact, the recency-based sorting is probably the slowest part, because after that all we're going by is length.

You might think that we shouldn't have to sort the whole list just to present recent candidates. The main issue is that candidates which were previously selected might no longer be present in the collection. For example, a file might have been deleted. It would be very confusing if such candidates appeared, especially if they then disappeared when the full sort was done.

I agree with you wholeheartedly that waiting even 500ms for M-x is quite unacceptable, but unfortunately I haven't been able to think of any good ways to optimize further that will not have massive disadvantages.

One solution, of course, is to see how much performance is improved by gccemacs: https://akrl.sdf.org/gccemacs.html#orgb905200

Fundamentally, prescient.el is not implementing a complex algorithm, nor is it processing a lot of data, so a large part of the blame for slowness I think can be placed on the Emacs Lisp language implementation itself.

Let me know if you have any ideas or thoughts on this.

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

No branches or pull requests

2 participants