From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH v1 4/8] box: load persistent Lua functions on creation References: <9ed730e31d6c261f64239f2f4124b98716770156.1559212747.git.kshcherbatov@tarantool.org> <20190531081641.GC31572@atlas> From: Kirill Shcherbatov Message-ID: <6d335ab5-79ed-b34c-7cc8-589396e97df3@tarantool.org> Date: Mon, 3 Jun 2019 11:26:29 +0300 MIME-Version: 1.0 In-Reply-To: <20190531081641.GC31572@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Konstantin Osipov Cc: vdavydov.dev@gmail.com List-ID: On 31.05.2019 11:16, Konstantin Osipov wrote: > * Kirill Shcherbatov [19/05/30 14:12]: > > Could you please benchmark how much slower is a function > invocation in a fresh sandbox compared to a re-cycled one? > > How many invocations per second can we get for a simple ffunction > like return a*a? Hi! I don't quite understand what you asked me to do. I measured performance in the following scenarios: Case 1. Function load lua_code = [[function(tuple) return tuple[1]*tuple[2] end]] box.schema.func.create('extract', {body = lua_code, is_deterministic = true, returns = 'integer'}) 1) function creation doesn't assemble a new sandbox, but makes a deepcopy of existent one (as on branch) 50830 FUNCTION LOADS/SEC 2) function creation assembles a new sandbox (with luaT_prepare_sandbox) and applies it (lua_setfenv) 49817 FUNCTION LOADS/SEC 3) function creation use an existent sandbox and doesn't make it's deepcopy (no monkey-patch protection between the extractors) 204188 FUNCTION LOADS/SEC Case 2. (part of the last patch) Function call "return 1": 914445 CALLS/SEC "return tuple[1] + tuple[2]": 882009 CALLS/SEC "sharonovAddrExtractor": 164499 CALLS/SEC