diff options
| author | Justin M. Keyes <justinkz@gmail.com> | 2026-04-17 19:10:20 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-04-17 19:10:20 -0400 |
| commit | 0d4d285bd2c19697164175280b32bf93e3a7b1da (patch) | |
| tree | 0aa20f3e342279e9cba36e5c8daa0d38b2507c8d /test/functional/vimscript/executable_spec.lua | |
| parent | 03193e2963a6f9333afc3090ad2c8002b648fe11 (diff) | |
perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166
Problem:
- Builtin "Vimscript" functions (f_xx) are mostly implemented in C.
Partly that's because there is some boilerplate required to call out
to Lua.
- Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript
("typval") bridge, even if `fn.foo()` is implemented entirely in Lua:
```
Lua => typval => Object => Lua => Object => typval => Lua.
```
Solution:
Functions declared in eval.lua with `func_lua` are implemented in
entirely in Lua (`_core/vimfn.lua`).
- `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles
the typval conversion for Vimscript callers (slow path).
- `nlua_call()` detects `func_lua` functions and calls the Lua
implementation directly. This eliminates all conversion overhead for
Lua callers (fast path).
- Validate at build-time that `func`, `func_float`, and `func_lua` are
mutually exclusive.
- Migrate `hostname()` as a toy example, to show the idea.
Diffstat (limited to 'test/functional/vimscript/executable_spec.lua')
0 files changed, 0 insertions, 0 deletions
