You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Call of _func functions creates a new lua_State via luaT_newthread(), and moves all the arguments to it. This is slow, probably very slow, but nobody measured properly. Should be most visible on C functions.
The new lua_State is not really needed - all can be done on the provided lua_State. For example, lbox_func_call() has a lua_State with all its arguments in it. No need to move them to a new state.
Why it is not done now I think is because port_lua does not support dumping not the entire lua_State. See encode_lua_call(). On the other hand the first argument is often a callable object (box.func.<name>, for example), which can't be popped from the stack (may trigger its GC). So an offset 1 would solve the problem.
The same will happen for the upcoming cbox module for calling C functions without touching the schema.
The text was updated successfully, but these errors were encountered:
Call of
_func
functions creates a newlua_State
vialuaT_newthread()
, and moves all the arguments to it. This is slow, probably very slow, but nobody measured properly. Should be most visible on C functions.The new
lua_State
is not really needed - all can be done on the providedlua_State
. For example,lbox_func_call()
has alua_State
with all its arguments in it. No need to move them to a new state.Why it is not done now I think is because
port_lua
does not support dumping not the entirelua_State
. Seeencode_lua_call()
. On the other hand the first argument is often a callable object (box.func.<name>
, for example), which can't be popped from the stack (may trigger its GC). So an offset 1 would solve the problem.The same will happen for the upcoming
cbox
module for calling C functions without touching the schema.The text was updated successfully, but these errors were encountered: