search

noib3 / nvim-completion

:zap: An async autocompletion framework for Neovim
MIT License
503 stars 13 forks source link

Performance Issue #1

Closed litao91 closed 2 years ago

litao91 commented 2 years ago

Hi, Have you ever tested the performance of mlua? From my experience, it's really slow to cross the boundary between the lua part and the rust part (i.e., calling a rust function from lua or calling a lua function from rust). I'm afraid that the performance will be an issue in the future.

Thanks

noib3 commented 2 years ago

The mlua crate is mostly used to interface with the neovim api to handle the UI: creating floating windows, moving them, filling their buffers, etc. This is all already implemented and I haven't found performance to be a problem, everything feels instantaneous.

However I can see how this could become a problem if a completion source heavily relies on the api, as that cost would be payed every keystroke.

The long term goal is to drop mlua entirely once Neovim stabilizes and exposes libnvim to directly talk to the C api (relevant issue here). For now there's not a lot that can be done since Lua is the only way to interact with Neovim.

sandangel commented 2 years ago

@noib3 hi, regardless mlua dependency, I would love to see a demo to compare with coq_nvim tho, is that something we can only have after adding completion source?

noib3 commented 2 years ago

@sandangel I plan to add a CompleetStats command showing infos about the performance of each source but yes, we gotta add at least one real source first.