Slow selection with many files

[SebastienWae]

Opening a new issue because #195 has been close for a few months.

Selectrum is very slow, 1-2 seconds delay between each key press and ui update, on a 61k+ list of file.

I have tried with and without orderless and prescient, it didn't made any changes.
Ivy with and without prescient has a much lower delay ~500 ms.

This is using Emacs native-comp branch on NixOS.

[clemera]

Oh, that are a lot of files :D

The problem is with file completions as I tested with

touch {1..60000}

And start completion using find-file, there is no problem with such large candidates sets in general:

(completing-read "Check: "
                 (mapcar #'number-to-string
                         (number-sequence 0 60000)))

This might also be connected to the reported tramp issues #210

[minad]

@clemera But if you use numbers, the strings are much shorter. I am sure this has some effect. Did you test many long strings? I mean there are the issues with long strings in the consult-help experiment.

[clemera]

Yes that also has an effect but the file problem still exists with the number example. The problem seems to be that the internal collection function is unusable slow with so many file as you can test using:

(read-file-name-internal "~/playground/files/" nil t)

[clemera]

We call it on every input change I guess a simple workaround would be to only recompute on directory change for file completions, that would still give you an initial delay but not on every keypress afterwards.

[minad]

Maybe check what ivy does differently - is there some internal API they work around and Selectrum cannot?

We call it on every input change I guess a simple workaround would be to only recompute on directory change for file completions, that would still give you an initial delay but not on every keypress afterwards.

This would fix the lagging when pressing keys.

[clemera]

Maybe check what ivy does differently - is there some internal API they work around and Selectrum cannot?

I checked and they use the same function, they are also equally slow initially but the result is cached so there is no lag on each input for ivy.

[clemera]

@SebastienWae
Could you test if #277 would work for you? Please disable sort before testing this by setting selectrum-should-sort-p to nil.

[SebastienWae]

@SebastienWae
Could you test if #277 would work for you? Please disable sort before testing this by setting selectrum-should-sort-p to nil.

It's much better!
I haven't timed it, but with sort enabled it feels at least as fast as Ivy and when disabled it's much faster.

Initial load time is still slow (but that's not really a Selectrum issue) and once it's loaded it only has a small delay which is more than acceptable considering the size of the list.

gif with sort enable:

[minad]

Initial load time is still slow (but that's not really a Selectrum issue) and once it's loaded it only has a small delay which is more than acceptable considering the size of the list.

Slower than ivy?

[SebastienWae]

Initial load time is still slow (but that's not really a Selectrum issue) and once it's loaded it only has a small delay which is more than acceptable considering the size of the list.

Slower than ivy?

I would have to benchmark it to be sure but it feels the same at ~1-2 seconds.
But the most important part is that once it's load it fast enough that I can use it.

[clemera]

With #277 merged can this be closed?