From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id E193F6EC55; Fri, 30 Jul 2021 01:38:55 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E193F6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1627598336; bh=uipkCF59TG8ra0JhGMSyin1DlVU5j6gsvX9A3VmoSr0=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=LN2W4dLszoSEjrtUal8eBrSRxkWPKDsDbqGnHsF9yZ4C6c9Z5aEc6SwbAPqCsJPGM XNurGT2rFq63mEkv9J8y3KMwY2n5Slly4JxONKX7pFoqldsFtUVptC6kv1CsPhVauI FbKqVMXcBKQaZ+9s/vzpI6ht6x6gjB8rfmAo28t0= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 DFC7B6EC55 for ; Fri, 30 Jul 2021 01:38:54 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DFC7B6EC55 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1m9Eg1-0000pS-S8; Fri, 30 Jul 2021 01:38:54 +0300 To: Vladimir Davydov Cc: tarantool-patches@dev.tarantool.org References: <0123065e-6352-331e-2dd8-b712b9d6e26a@tarantool.org> <20210729113313.fmq2fo4vpkrdusp7@esperanza> <20210729152316.boj2wdhfn6wr26j2@esperanza> Message-ID: <6baa639d-8c94-000d-cd56-9189b3cc7dc9@tarantool.org> Date: Fri, 30 Jul 2021 00:38:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210729152316.boj2wdhfn6wr26j2@esperanza> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C3104FC76DFAAAAF7DA068FE323FAC4379182A05F5380850407AD1B280E30EC3DB28776659B71EDB6501ECAFCD9116AA716FCD282FD2BA5007 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7978947DCA0D4215FEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637225475490A77DC518638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D85E3D8025DECBF6CE2B1A047F67171EF1117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCAA867293B0326636D2E47CDBA5A96583BD4B6F7A4D31EC0BC014FD901B82EE079FA2833FD35BB23D27C277FBC8AE2E8B3A703B70628EAD7BA471835C12D1D977C4224003CC8364762BB6847A3DEAEFB0F43C7A68FF6260569E8FC8737B5C2249EC8D19AE6D49635B68655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7C468D16C903838CAB43847C11F186F3C59DAA53EE0834AAEE X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A213B5FB47DCBC3458834459D11680B505799D5D3243E1C977FDF19D63BCF1A791 X-C1DE0DAB: 0D63561A33F958A503BB7F2CEC8F09406B7A5B1B55A80E14BD2B76C5826849F3D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA753530422897FB34C3410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34EE19B6E2433CA093732A9E04178E532BDC4F80F2DC57AD32E3BE3D5565153DAE7F5E564176BDD6DA1D7E09C32AA3244CD852FA954A0EF937112A692BB5E915A13C6EB905E3A8056B729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojPp/mPgZxawHkQGYzXwfN/Q== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D6EC1425D31044A888E9455E1CEE292853841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 00/20] Rewrite performance critical parts of net.box in C X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" >>>> Asynchronous calls don't show as much of an improvement as synchronous, >>>> because per each asynchronous call we still have to create a 'future' >>>> object in Lua. Still, the improvement is quite noticeable - 30% for >>>> REPLACE, 10% for UPDATE, 20% for SELECT, 25% for CALL. >>> >>> I didn't reach the end of the patchset yet, but did you try to create >>> the futures as cdata objects? They could be allocated on mempool, their >>> GC pressure might be optimized by doing similar to luaT_tuple_encode_table_ref >>> optimization (there was found a way to make __gc and other C functions >>> cheaper when it comes to amount of GC objects in Lua). >>> >>> The API would stay the same, they just would become C structs with >>> methods instead of Lua tables. >> >> Good call. Going to to try that. Thanks. > > Quickly whipped up a patch that converts userdata and cdata. Applied on > top of the series. Surprisingly, it only made things worse: > > With the patch (future is cdata): > > ==== FUTURE ==== > REPLACE: WALL 221.182 PROC 343.368 KRPS > UPDATE: WALL 178.918 PROC 291.504 KRPS > SELECT: WALL 220.815 PROC 248.843 KRPS > CALL: WALL 218.313 PROC 315.670 KRPS > > > Without the patch (future is userdata): > > ==== FUTURE ==== > REPLACE: WALL 262.454 PROC 450.425 KRPS > UPDATE: WALL 191.538 PROC 322.888 KRPS > SELECT: WALL 288.498 PROC 333.393 KRPS > CALL: WALL 247.463 PROC 375.180 KRPS > > The patch is below. Note, it isn't entirely correct - future:pairs > doesn't work, because luaL_checkcdata doesn't seem to handle upvalues, > but it shouldn't affect the test. Sorry, the patch can't be applied on top of the branch somewhy. But I see now that you already had the futures as C objects even before my proposal on top of the branch, so perhaps this is expectable that not much improved. However there is an idea which might make the perf gap smaller. > @@ -1642,10 +1649,14 @@ netbox_perform_async_request_impl(struct lua_State *L, int idx, > static int > netbox_perform_async_request(struct lua_State *L) > { > - struct netbox_request *request = lua_newuserdata(L, sizeof(*request)); > + struct netbox_request *request = mempool_alloc(&netbox_request_pool); > + if (request == NULL) > + return luaL_error(L, "out of memory"); > netbox_request_create(request); > - luaL_getmetatable(L, netbox_request_typename); > - lua_setmetatable(L, -2); > + *(struct netbox_request **) > + luaL_pushcdata(L, CTID_STRUCT_NETBOX_REQUEST_PTR) = request; > + lua_pushcfunction(L, luaT_netbox_request_gc); Here is the problem, which I mentioned in my email. lua_pushcfunction() is an expensive thing because it pushes a new GC object on the stack every time. It was happening in a few hot places before, and there is now a solution that for such cfunctions we push them only once, remember their ref like luaT_tuple_encode_table_ref does, and then re-push the same finalizer for each cdata object. See ec9a7fa7ebbb8fd6e15b9516875c3fd1a1f6dfee and e88c0d21ab765d4c53bed2437c49d77b3ffe4216. You need to do lua_pushcfunction(L, luaT_netbox_request_gc); only once somewhere in netbox_init() or something. Then netbox_request_gc_ref = luaL_ref(L, LUA_REGISTRYINDEX); Then in netbox_perform_async_request() you make lua_rawgeti(L, LUA_REGISTRYINDEX, netbox_request_gc_ref); luaL_setcdatagc(L, -2); I think this should help. But I doubt it will help too much though.