From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 962B9469719 for ; Fri, 16 Oct 2020 01:11:00 +0300 (MSK) References: <33039bab-b31e-0da7-359d-dbbc8464aa55@tarantool.org> <20201012103707.kzx54ljqq67eazrc@tkn_work_nb> <965ed904-a5d5-f0b6-a779-d120ec9761f0@tarantool.org> <20201015194346.ptzvea2tvv7m3cgt@tkn_work_nb> From: Vladislav Shpilevoy Message-ID: <41a4efbb-d0f6-fc17-d37b-1df7519d3c95@tarantool.org> Date: Fri, 16 Oct 2020 00:10:59 +0200 MIME-Version: 1.0 In-Reply-To: <20201015194346.ptzvea2tvv7m3cgt@tkn_work_nb> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v2 05/15] lua: don't raise a Lua error from luaT_tuple_new() List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org 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})