perf: improve for source providing huge list of items
Problem
nvim-cmp is still not ideally responsive when dealing with huge list of completion items, especially with tailwindcss which sends thousands of candidates on each completion response: #1009 #1828 #1949. Though some improvements have been done before but cmp is still apparently slower than other completion engine like vscode and coc.nvim in extreme cases.
Attempt to improve
This PR extracts two commits from my experimental perf branch fork which I think could be better upstreamed. The details and rationales are explained in commit descriptions.
The commits introduce massive changes to the codebase, and I'm not sure if you'd like to accept them. Since the changes are made just for improving performance in extreme cases, it's totally fine for me if you consider that it is not worth it.
Comparison
Recorded at https://github.com/hrsh7th/nvim-cmp/commit/a110e12d0b58eefcf5b771f533fc2cf3050680ac:
PR:
Good jobs. This plugin is still very useful. Unfortunately, the author doesn't seem to have much time to maintain this plugin.
@hrsh7th please let's get this performance boost in asap
But it seems draft state. It is ready to merge?
I tested this by forking @yioneko and there is a huge difference in the autocompletion. Everything works like the same - just better.
I also tested it by forking the original nvim-cmp and copying this PR changes over, and things seems to break. Could be because it's few commits behind which are kinda deal-breaking!
@idelice Could you expand on what is breaking? I just rebased the branch onto the main locally and it seems to work fine as before. I've been using this for about one month personally without issues and I think this is generally ready for review if no more problems found.
@idelice Could you expand on what is breaking? I just rebased the branch onto the main locally and it seems to work fine as before. I've been using this for about one month personally without issues and I think this is generally ready for review if no more problems found.
I don't know. I'm not familiar with lua enough to pinpoint what caused my user-testing to fail
Hm... I think more testers are needed.
Works well so far 😄
It works fine for me, no issues. I'll be using this fork for now, @yioneko thanks for the improvement!
This is awesome, but why is it still draft? @yioneko you feel like its not ready yet?
I think this is generally ready for review. It might do not matter whether the PR status is draft or open as it seems that it would take a while to receive response from the owner, so I'll just change it to indicate that the branch here is open to user testing.
About the CI failing: https://github.com/leafo/gh-actions-lua/issues/49 and it passed before the rebase and all the tests are passed on my local environment.
Hopefully this will be merged, can't wait to test it.
Tested with cmp-dictionary, and with 1000 items this branch is 6x faster, 300ms vs 2s 🚀
I know I could use this PR personally but I still desire it gets merged and I believe it must benefit every user. Apologize sincerely for the ping @hrsh7th .
I tested the PR and I also noticed a big improvement in performance.
I tested this PR and noticed a significant improvement in performance. I haven't encountered any bugs. (yet?)
Hello! I would like to kindly ask if there is any news about the testing outcome
Sorry for the late reply. I'll do review.
My last review subject is entry.lua, which is a bit complicated. It will take some time.