From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 4FE4D469719 for ; Thu, 15 Oct 2020 22:43:27 +0300 (MSK) Date: Thu, 15 Oct 2020 22:43:46 +0300 From: Alexander Turenko Message-ID: <20201015194346.ptzvea2tvv7m3cgt@tkn_work_nb> References: <33039bab-b31e-0da7-359d-dbbc8464aa55@tarantool.org> <20201012103707.kzx54ljqq67eazrc@tkn_work_nb> <965ed904-a5d5-f0b6-a779-d120ec9761f0@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <965ed904-a5d5-f0b6-a779-d120ec9761f0@tarantool.org> 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org 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.