Skip to content
This repository has been archived by the owner on Dec 19, 2022. It is now read-only.

advanced guide: content #43

Open
matu3ba opened this issue Feb 8, 2021 · 1 comment
Open

advanced guide: content #43

matu3ba opened this issue Feb 8, 2021 · 1 comment

Comments

@matu3ba
Copy link
Contributor

matu3ba commented Feb 8, 2021

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 Mention vim.api.nvim_call_function #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): A Lua-aware startup time profiler nvim-lua/wishlist#15 (comment)
  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
Copy link

pkazmier commented Jul 4, 2022

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants