From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 7360E469710 for ; Tue, 19 May 2020 13:29:33 +0300 (MSK) Date: Tue, 19 May 2020 13:29:24 +0300 From: Sergey Kaplun Message-ID: <20200519102924.GA27691@root> References: <20200518093748.16825-1-skaplun@tarantool.org> <74b93f1b-5515-6f8a-32d6-4672e312eb51@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74b93f1b-5515-6f8a-32d6-4672e312eb51@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] lua: lua_field_inspect_table without pushcfunction List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Hi! Thanks for the review! On 18.05.20, Vladislav Shpilevoy wrote: > On 18/05/2020 11:37, Sergey Kaplun wrote: > > Currently on encoding table we push cfunction (lua_field_try_serialize) > > to lua stack with additional lightuserdata and table value and after > > pcall that function to avoid a raise of error. > > > > In this case LuaJIT creates new object which will not live long time, > > so it increase amount of dead object and also increase time and > > frequency of garbage collection inside LuaJIT. > > Also this pcall is necessary only in case when metafield __serialize > > of serilizable object has LUA_TFUNCTION type. > > > > So instead pushcfunction with pcall we can directly call the function > > trying to serialize an object. > > --- > > 1. Is there a measurement, how much does this patch help and when, > exactly? I was faced this when I was looking at the flamegraphs by Aleksandr Lyapunov related to https://github.com/tarantool/vshard/issues/224 At vshard_router.svg you can see that mp_encode_lua call-chain comes to luamp_inspect_table, with pushcfunction and gc_step respectively. So I suppose that simple test with mp_lua_encode would be enough (see example below) to see a difference. Note: for your local machine 1e5-1e6 itterations would be ok. | 20:15:42 jobs:0 s.kaplun@dev4:~/tarantool_builds/lua_mp_pcall$ | >>> src/tarantool | Tarantool 2.5.0-32-g7f20272 | type 'help' for interactive help | tarantool> c1_source = { | setmetatable({[180] = 10, [1] = 0}, {__serialize = "map"}), | setmetatable({ | [34] = "vshard.router.call_rw", | [33] = {148, 0, "bench_call_select_r"} | }, {__serialize = "map"}) | } | --- | ... | | tarantool> local msgpack = require"msgpack" | local clock = require"clock" | local S = clock.proc() | for i=1,1e7 do msgpack.encode(c1_source) end | return clock.proc() - S | --- | - 9.968856686 | ... | | tarantool> 21:00:32 jobs:0 s.kaplun@dev4:~/tarantool_builds/lua_mp_pcall$ | >>> ../master/src/tarantool | Tarantool 2.5.0-32-g7f20272 | type 'help' for interactive help | tarantool> c1_source = { | setmetatable({[180] = 10, [1] = 0}, {__serialize = "map"}), | setmetatable({ | [34] = "vshard.router.call_rw", | [33] = {148, 0, "bench_call_select_r"} | }, {__serialize = "map"}) | } | --- | ... | | tarantool> local msgpack = require"msgpack" | local clock = require"clock" | local S = clock.proc() | for i=1,1e7 do msgpack.encode(c1_source) end | return clock.proc() - S | --- | - 12.622932064 -- Best regards, Sergey Kaplun