[Tarantool-patches] [PATCH v2 05/15] lua: don't raise a Lua error from luaT_tuple_new()

[Vladislav Shpilevoy]

On 15.10.2020 21:43, Alexander Turenko wrote:
> On Thu, Oct 15, 2020 at 01:41:45AM +0200, Vladislav Shpilevoy wrote:
>> On 12.10.2020 12:37, Alexander Turenko wrote:
>>>>> Disallow creating a tuple from objects on the Lua stack (idx == 0) in
>>>>> luaT_tuple_new() for simplicity. There are no such usages in tarantool.
>>>>> The function is not exposed yet to the module API. This is only
>>>>> necessary in box.tuple.new(), which anyway raises Lua errors by its
>>>>> contract.
>>>>
>>>> 1. But why? The case of creating a tuple from values may be much faster,
>>>> when there is a lot of values not wrapped into a table. Table wrap is
>>>> costly.
>>>>
>>>> Could you just merge luaT_tuple_encode_values and luaT_tuple_encode_table
>>>> into one function, withuout splitting them?
>>>
>>> I started with this variant, but then found that it'll require copying
>>> of all arguments before pcall() (at least if we must leave them on the
>>> stack after exiting from the function). Even if we'll decide to include
>>> a remark like 'the function pops all values in case of idx == 0', we'll
>>> need to put a function before the arguments and so we'll move all stack
>>> values. Anyway it looks lopsided: in one case arguments are popped, but
>>> in another they are kept on the stack.
>>>
>>> I guess it would have a chance to be useful if it would allow to pass a
>>> range of lua stack indices. But not sure.
>>
>> I created an issue for that: https://github.com/tarantool/tarantool/issues/5406
>> (At least it is related, and this place is not the only problematic one.)
> 
> Hmm. I don't see how it is related to the question.

When the issue is fixed, we will be able to serialized a range of values,
without them being places on top of the stack. So it will make it faster
to call

	box.tuple.new(1, 2, 3, 4, 5)

than

	box.tuple.new({1, 2, 3, 4, 5})