From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 A3D0E469710 for ; Wed, 6 May 2020 14:17:22 +0300 (MSK) Date: Wed, 6 May 2020 14:17:06 +0300 From: Alexander Turenko Message-ID: <20200506111706.m6vxgduyaa3ay3mr@tkn_work_nb> References: <20191114115020.21091-1-maria.khaydich@tarantool.org> <1583942274.319390956@f377.i.mail.ru> <20200312132931.GA30900@atlas> <1584041112.66796082@f172.i.mail.ru> <20200312200024.GA11476@atlas> <20200318222635.GG6392@tarantool.org> <20200319071920.GA3227@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200319071920.GA3227@atlas> Subject: Re: [Tarantool-patches] [PATCH 1/2] box: make box.cfg idempotent function List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org > > However you might suggest another fix for the issue? There are several > > other ways to indicate whether box is configured, e.g. introduce the > > specific value to the box table. What do you think? > > Why not set a lua variable *from* C instead of calling from Lua > *into* C each time? This way it will be slower when called from C. Since we unable to 'unconfigure' box I would just cache C's value in Lua. C's box_is_configured() is used only in box.session.su() and its performance is not so critical as box.execute(). However I don't see a reason to slowdown C's box_is_configured()() if we can avoid it: it may be important if it will be called from some other code. I don't sure, but storing database settings and state in Lua looks a bit lopsided approach for me: even now we have three languages: C, Lua and SQL. Some caching, hovewer, is okay. > I mean, this is an obvious optimization, but it is only worth it > if there is a measurable slowdown (which I suspect there is, at > least a couple of %, but even a couple of % IMHO justify it). I failed to obtain stable results and maybe there is a difference, but I don't see it now. https://gist.github.com/Totktonada/407855389ed4da93bf0175cf8a11c7b9 I made those measurements on fixed CPU frequency and 10 times run each implementation 10 times: 300 runs at whole. I see that results becomes worse for all implementations from run to run. Looks strange. WBR, Alexander Turenko.