Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v2 05/15] lua: don't raise a Lua error from luaT_tuple_new()
Date: Fri, 16 Oct 2020 00:10:59 +0200	[thread overview]
Message-ID: <41a4efbb-d0f6-fc17-d37b-1df7519d3c95@tarantool.org> (raw)
In-Reply-To: <20201015194346.ptzvea2tvv7m3cgt@tkn_work_nb>

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})

  reply	other threads:[~2020-10-15 22:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-11 12:57 [Tarantool-patches] [PATCH v2 00/15] RFC: module api: extend for external key_def Lua module Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 01/15] module api: get rid of typedef redefinitions Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 02/15] module api: expose box region Alexander Turenko
2020-10-11 15:26   ` Vladislav Shpilevoy
2020-10-12  6:07     ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 03/15] module api/lua: add luaL_iscdata() function Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 04/15] lua: factor out tuple encoding from luaT_tuple_new Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 05/15] lua: don't raise a Lua error from luaT_tuple_new() Alexander Turenko
2020-10-11 15:25   ` Vladislav Shpilevoy
2020-10-12 10:37     ` Alexander Turenko
2020-10-12 13:34       ` Timur Safin
2020-10-14 23:41       ` Vladislav Shpilevoy
2020-10-15 19:43         ` Alexander Turenko
2020-10-15 22:10           ` Vladislav Shpilevoy [this message]
2020-10-11 17:47   ` Igor Munkin
2020-10-11 18:08     ` Igor Munkin
2020-10-12 10:37     ` Alexander Turenko
2020-10-12 10:51       ` Igor Munkin
2020-10-12 18:41         ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 06/15] WIP: module api/lua: add luaT_tuple_encode() Alexander Turenko
2020-10-11 15:25   ` Vladislav Shpilevoy
2020-10-12 10:35     ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 07/15] module api/lua: expose luaT_tuple_new() Alexander Turenko
2020-10-11 15:25   ` Vladislav Shpilevoy
2020-10-12  6:11     ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 08/15] module api/lua: add API_EXPORT to tuple functions Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 09/15] module api: add API_EXPORT to key_def functions Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 10/15] module api: add box_key_def_new_v2() Alexander Turenko
2020-10-11 15:25   ` Vladislav Shpilevoy
2020-10-12  7:21     ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 11/15] module api: add box_key_def_dump_parts() Alexander Turenko
2020-10-11 15:25   ` Vladislav Shpilevoy
2020-10-12  6:50     ` Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 12/15] module api: expose box_key_def_validate_tuple() Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 13/15] WIP: module api: expose box_key_def_merge() Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 14/15] WIP: module api: expose box_key_def_extract_key() Alexander Turenko
2020-10-11 12:57 ` [Tarantool-patches] [PATCH v2 15/15] WIP: module api: add box_key_def_validate_key() Alexander Turenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41a4efbb-d0f6-fc17-d37b-1df7519d3c95@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v2 05/15] lua: don'\''t raise a Lua error from luaT_tuple_new()' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox