Closed litao91 closed 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.
@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?
@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.
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