From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (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 039F4469719 for ; Mon, 16 Nov 2020 10:50:33 +0300 (MSK) References: <20201114172823.8217-1-sergepetrenko@tarantool.org> From: Serge Petrenko Message-ID: <6a8c6d09-0852-9544-c3e5-9ce44d22d6bf@tarantool.org> Date: Mon, 16 Nov 2020 10:50:32 +0300 MIME-Version: 1.0 In-Reply-To: <20201114172823.8217-1-sergepetrenko@tarantool.org> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [Tarantool-patches] [PATCH 0/2] reduce performance degradation introduced by JSON path indices List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: v.shpilevoy@tarantool.org, korablev@tarantool.org Cc: tarantool-patches@dev.tarantool.org Issue: https://github.com/tarantool/tarantool/issues/4774 Branch: sp/gh-4774-multikey-refactoring 14.11.2020 20:28, Serge Petrenko пишет: > The patchset fixes two degradations found by measuring snapshot recovery time > for a 1.5G snapshot containing 30M tuples in a memtx space with a simple primary > key and one secondary key over 4 integer and one string field. > > The first degradation manifests itself during snapshot recovery phase (the one > with "3.5M rows processed" messages) and is connected to `memtx_tuple_new` > slowdown due to unoptimised `tuple_field_map_create`. > > First patch deals with this degradation and manages to restore almost all > performance lost since 1.10. (The patched version is only 11% slower than 1.10, > while the current master is 39% slower on this phase). > > The second degradation appears during next snapshot recovery phase, secondary > index building. Here the degradation is rooted in slow tuple field access via > tuple_field_raw(). > > The second patch deals with this issue and manages to restore part of the lost > performance. (The patched version is 14% slower than 1.10 while the current > master is 27% slower). > > Serge Petrenko (2): > box: speed up tuple_field_map_create > box: use tuple_field_raw_by_part where possible > > src/box/tuple_compare.cc | 37 ++++----------- > src/box/tuple_extract_key.cc | 10 +--- > src/box/tuple_format.c | 91 ++++++++++++++++++++++++++++++++++++ > src/box/tuple_hash.cc | 35 ++++---------- > 4 files changed, 111 insertions(+), 62 deletions(-) > -- Serge Petrenko