use timer to improve the ivy-read performance

[redguardtoo]

This trick is used frequently in javascript search box.

When user input characters, don't update the collection display immediately. Cache the user input until user has not input any new characters say for 1 second.

After one second, we continue the UI update.

Could you at least make a option for ivy-read like :seconds-wait-for-user-input. Its default value is zero which means updating UI immediately. But if it's more than zero, UI will wait to make sure the user finish the input.

[ambihelical]

I tried hacking the new delay code added by @jeberger used for dynamic collections by disabling the actual check for dynamic collection. It works well except for up/down movements which are also delayed. Probably something would need to be done to allow ivy--queue-exhibit to call ivy--exhibit with filtering disabled so the list can be updated quickly. However besides this issue, it is a great quality of life improvement for really large trees and counsel-find-file or similar. I ended up using 200ms delay which seems to suit my typing speed. With an AOSP tree using counsel-projectile-find-file, I was seeing >1s delay or more per character typed. Now I can actually type whole words before the filtering kicks in.

[randymorris]

Sorry for digging up an old topic here, but I'm in pretty much the same exact situation as @ambihelical described. Any tips on implementing this hack so I can get by until this issue gets some attention?

[redguardtoo]

(setq ivy-dynamic-exhibit-delay-ms 250)

[randymorris]

Unfortunately that doesn't help me here because the collection provided by counsel-projectile-find-file is not dynamic. Setting that timeout has no effect in this case.

[abo-abo]

@randymorris If I understood correctly, your problem with counsel-projectile-find-file is the start-up cost. There isn't much that can be done here, since we need to call projectile-current-project-files which creates the list of files. After the list is created, the filtering should be very fast.

@redguardtoo Can this issue be closed?

[randymorris]

Startup time is noticeable but acceptable. My issue is that the filtering happens on each keypress. Often I type a second, third, or fourth key before the filtering finishes for the first keypress. This leads to me having to wait for the filtering to happen four times before I can see what keys I need to press to filter further.

Debouncing as described in the original issue would make the filtering happen only after a timeout rather than after every keypress, just as appears to be implemented for dynamic collections.

The way I see it I have two options:

1. Somehow make non-dynamic collections have the same behavior that ivy-dynamic-exhibit-delay-ms provides for dynamic collections.
2. Make counsel-projectile-find-file provide a dynamic collection and set ivy-dynamic-exhibit-delay-ms appropriately.

[abo-abo]

My issue is that the filtering happens on each keypress. Often I type a second, third, or fourth key before the filtering finishes for the first keypress.

That sounds really bad, I've never noticed such poor performance. What's the amount of candidates you have and what config are you using?

[randymorris]

The collection of candidates for me was just under 8,000 files. In coming up with a minimal config to give you, I found that this is the culprit:

(setq ivy-re-builders-alist '((t . ivy--regex-fuzzy)))

I think I had followed this post when I migrated to ivy a long time ago, thus I've always had this issue and not realized that the fuzzy matching was the cause. I suppose this "fixes" it for me, although I'll have to get used to the less fuzzy matching if I want it to be fast. I still think that debouncing the keypresses even with a non-dynamic collection is probably not a bad idea.

Thanks for taking the time to reply, and again, sorry for digging up an old topic.

[ambihelical]

I was dealing with a tree with about 200-400K candidates (an AOSP tree), I don't remember the exact number of files it had to filter through, but it was in that range. I added the hack I mentioned to deal with it, with good results, although there were some issues. I don't use fuzzy matching though. You can see the hack I am using in my fork of swiper, branch try-async.

[redguardtoo]

@randymorris, try find-file-in-project-by-selected from https://github.com/technomancy/find-file-in-project

It's much faster.

[abo-abo]

@randymorris I see, I suspected that ivy--regex-fuzzy was the issue. Could you test it with and without flx installed? I wonder if most of the time is being spent on filtering the candidates or sorting them by frequency.