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 3F5AE6EC55; Thu, 29 Jul 2021 14:33:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3F5AE6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1627558396; bh=LYhSt8e/gkoBRZFMtAFP0bjkiR7CiovvHnuPqk6SmQc=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=mosL2eauwZ25CQgmHatBXDkkT8E4NajsKBRCe6WWzbUI+DPi89sl04hKLZwwsDHG/ 3VQYuGIPm2rBsJVoAb+VIweNxDHPrxOBnsG6b1AsseZK30NGQBq0fxNUm728z6SNOz 9ab4fjHOo+xHyd0X3oRpF54+B5dEL8G2bTTypYMw= 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 25BE56EC55 for ; Thu, 29 Jul 2021 14:33:15 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 25BE56EC55 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1m94Hq-0002l4-GL; Thu, 29 Jul 2021 14:33:14 +0300 Date: Thu, 29 Jul 2021 14:33:13 +0300 To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Message-ID: <20210729113313.fmq2fo4vpkrdusp7@esperanza> References: <0123065e-6352-331e-2dd8-b712b9d6e26a@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0123065e-6352-331e-2dd8-b712b9d6e26a@tarantool.org> X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C366EE405EC28A2001F8302D8429E0DE58182A05F538085040612E0A10DA2A37B9B1D22B0B73297C697ADEADBC6B900DC64124EDCDE60170B5 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE79488F21A45FBCE3EEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006370FDF1CE57EA9D07C8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D874F7BA9A4E7D3F92C0630A6120517795117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8B569F1129A2C6445075ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A526312C69CD9D831246E559DDE49C2A40E241BE8572CD6504D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA753530422897FB34C3410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3433E9BC74ABA5769F80BFAF0547517353ED74EF5A6CD32636EE590D70700905A54A292C933625D7E01D7E09C32AA3244C45B68CC254DC997FF4D850BE6AE565D824AF4FAF06DA24FDFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojPp/mPgZxawEa8Yx9H5ugDg== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D934F2E56E2D705B8FDD7DD46E786E7AF274CEFED1673C562683ABF942079399BFB559BB5D741EB966A65DFF43FF7BE03240331F90058701C67EA787935ED9F1B 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: Vladimir Davydov via Tarantool-patches Reply-To: Vladimir Davydov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Thu, Jul 29, 2021 at 12:51:18AM +0200, Vladislav Shpilevoy wrote: > Hi! Thanks for the patchset! > > Here is a first part of my review. I will return later to continue. > > Commits 02-05, 07-08, 10 are LGTM. Pushed to master. > > > 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.