perf: vim.fn.executable is slow

[rewhile]

After lazy.nvim 11.0 was released my config startuptime went from 25ms to 85ms

I have traced back the slowness due to this line:

lazy.nvim/lua/lazy/core/config.lua

Line 53 in 8dd947f

hererocks = vim.fn.executable("luarocks") == 0,

> time nvim --headless -c ':lua local s = vim.loop.hrtime() vim.fn.executable("luarocks") print(string.format("%fms\n", (vim.loop.hrtime() - s) / 1000000))' +q

60.269405ms
nvim --headless -c  +q  0.04s user 0.03s system 39% cpu 0.184 total

[folke]

That is super weird, since vim.fn.executable should be really fast (and is negligible in my setup).
What OS are you on?

Also, can you run the same test, but with vim.uv.exepath instead?

[folke]

On my system:

❯ time nvim --headless -c ':lua local s = vim.loop.hrtime() vim.fn.executable("luarocks") print(string.format("%fms\n", (vim.loop.hrtime() - s) / 1000000))' +q

0.032316ms

[rewhile]

vim.uv.exepath seems to be very fast :)

EDIT: It doesn't seem to have the same behavior

❯ time nvim --headless -c ':lua local s = vim.loop.hrtime() vim.uv.exepath("luarocks") print(string.format("%fms\n", (vim.loop.hrtime() - s) / 1000000))' +q

0.009027ms
nvim --headless -c  +q  0.02s user 0.03s system 45% cpu 0.107 total

[folke]

Allright, I can change it I guess, but you should still figure out why vim.fn.executable is that slow on your machine.
That really doesn't seem right.

That function is used by a lot of plugins and internally by Neovim.

Is it fast when checking a binary that you do have on your path?

[folke]

nm, vim.uv.exepath doesn't do what vim.fn.executable does

[folke]

Closing, since this not a lazy.nvim issue.

For more info, see
https://neovim.io/doc/user/builtin.html#executable()

[rewhile]

Ok after I turned off windows WSL's appendWindowsPath it is fast again

❯ time nvim --headless -c ':lua local s = vim.loop.hrtime() vim.fn.executable("luarocks") print(string.format("%fms\n", (vim.loop.hrtime() - s) / 1000000))' +q

0.037370ms
nvim --headless -c  +q  0.03s user 0.00s system 67% cpu 0.048 total

However, since this is the default behavior of WSL it might still be worth it to defer this function.

[folke]

I just pushed a changed so that that check only happens when needed