Tarantool development patches archive
 help / color / mirror / Atom feed
From: Serge Petrenko <sergepetrenko@tarantool.org>
To: korablev@tarantool.org
Cc: tarantool-patches@dev.tarantool.org
Subject: [Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices
Date: Fri,  4 Dec 2020 12:52:53 +0300	[thread overview]
Message-ID: <cover.1607075291.git.sergepetrenko@tarantool.org> (raw)

https://github.com/tarantool/tarantool/issues/4774
sp/gh-4774-multikey-refactoring

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 all the lost
performance. (The patched version is 10% faster(!) than 1.10 while the current
master is 27% slower).
To be honest, the increase in speed between 1.10 and the second patch must be
due to tuple comparison hints. Otherwise the patched version should be even with
1.10, since it uses literally the same code as 1.10 did (with minor changes).

Changes in v2:
  - win some more performance by accessing top level
    tuple format fields directly (bypass the json_tree_lookup)
  - instead of relying on offset_slot_hint in the second patch,
    rewrite tuple_field_raw so that it doesn't check for path
    this wins a whopping 24% of perf compared to the previous
    version.

Changes in v3:
  - minor typo fixes

Serge Petrenko (2):
  box: speed up tuple_field_map_create
  box: refactor tuple_field_raw to omit path checks

 src/box/tuple.h        | 29 ++++++++++++++--
 src/box/tuple_format.c | 75 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 102 insertions(+), 2 deletions(-)

-- 
2.24.3 (Apple Git-128)

             reply	other threads:[~2020-12-04  9:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  9:52 Serge Petrenko [this message]
2020-12-04  9:52 ` [Tarantool-patches] [PATCH v3 1/2] box: speed up tuple_field_map_create Serge Petrenko
2020-12-10 17:17   ` Nikita Pettik
2020-12-11  6:34     ` Serge Petrenko
2020-12-11 14:32       ` Nikita Pettik
2020-12-04  9:52 ` [Tarantool-patches] [PATCH v3 2/2] box: refactor tuple_field_raw to omit path checks Serge Petrenko
2020-12-10 17:25   ` Nikita Pettik
2020-12-11  6:36     ` Serge Petrenko
2020-12-10 17:35 ` [Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices Nikita Pettik
2020-12-11  6:47   ` Serge Petrenko
2020-12-11 13:39   ` Alexander V. Tikhonov
2020-12-11 14:51     ` Nikita Pettik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1607075291.git.sergepetrenko@tarantool.org \
    --to=sergepetrenko@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox