Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: Serge Petrenko <sergepetrenko@tarantool.org>, avtikhon@tarantool.org
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices
Date: Thu, 10 Dec 2020 17:35:23 +0000	[thread overview]
Message-ID: <20201210173523.GE1319@tarantool.org> (raw)
In-Reply-To: <cover.1607075291.git.sergepetrenko@tarantool.org>

On 04 Dec 12:52, Serge Petrenko wrote:
> 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).

To Serge: I guess we should reflect this fix in user's changelog.
Could you please provide a few lines about patches?

To Alexander: we are going to push this patch to master. Could you verify
that it doesn't break any tests? Branch is:
https://github.com/tarantool/tarantool/tree/sp/gh-4774-multikey-refactoring
 
> 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)
> 

  parent reply	other threads:[~2020-12-10 17:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  9:52 Serge Petrenko
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 ` Nikita Pettik [this message]
2020-12-11  6:47   ` [Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices 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=20201210173523.GE1319@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=sergepetrenko@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