[Tarantool-patches] [PATCH v3 0/2] reduce performance degradation introduced by JSON path indices

[Nikita Pettik]

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)
>