search

nanotee / nvim-lua-guide

A guide to using Lua in Neovim
5.83k stars 220 forks source link

advanced guide: content #43

Open matu3ba opened 3 years ago

matu3ba commented 3 years ago

The one and only luajit wiki and luajit not yet implemented.

  1. Performance tips: wiki + wait for status information, computing performance guide recommended by scilua author

  2. Debugging: one step for vimkind

  3. luarocks => [wbthomason/packer.nvim] has now support luarocks packages => add firejail profile for luarocks done, but I want to test it further before upstreaming. Currently I have weird folder quirks.

  4. :checkhealth integration => check core and treesitter implementation

  5. Explaining what is most performant and why (vim.api) and what happens under the hood ie for vim.call,vim.fn etc. (blocked by missing documentation upstream) see #6 https://www.reddit.com/r/neovim/comments/oeevcy/what_is_the_difference_between_vimapi_and_vimfn/h45ujiz?utm_source=share&utm_medium=web2x&context=3 "What is the difference between vim.api and vim.fn functions?" "you can no longer use api functions from vim.fn which used to be the case vim.api is nvim specific functions and it goes from lua -> C while vim.fn is viml functions which goes from lua -> viml -> C there's more overhead for using vim.fn than vim.api"

  6. Some internal functions (categories?) and how to find more etc

Plugin guidelines:

  1. dont autostart lua stuff from vimscript: let the user handle it (for example using plugin folder makes profiling annoying/kinda breaks it): https://github.com/nvim-lua/wishlist/issues/15#issuecomment-782441170
  2. "Note that underscore-prefixed functions (e.g. "_os_proc_children") are internal/private and must not be used by plugins"
    => dont use underscopre-prefixed functions
  3. Guidelines how to name functions. local function a = bla() vs local a = function(). Related function M.bla() for a table.

I copied some content to the plugin template project and will delete this issue, once the stuff is documented there properly.

pkazmier commented 2 years ago

I've been reading the guide and I'm trying to understand the difference in performance between vim.api and vim.fn. In the reddit thread, now closed for comments, it mentions that vim.api is faster than using vim.fn because the api goes direct to C while fn goes to vimscript then to C.

However, while reading the neovim help, it mentions that vim.api is implemented using named sockets on the local system and message pack, which seems to imply that all calls have to round trip via kernel and socket. I'm trying to understand if the vim.fn bridge uses vim.api under the covers or if it is "native" and can invoke functions directly without the overhead of the socket and message pack.

If it is the latter, would performance be best described as:

vim.api -> socket/message pack -> C vim.fn -> vimscript -> C

And then the question becomes is there more overhead with with socket/kernel roundtrip or vimscript intermediary steps?

To summarize with an example, I guess I'm just wondering if every vim.api call must be go through the named socket and be serialized. If so, would vim.api.nvim_get_lines be less "efficient" than using vim.fn.getbufline?