Re: [Tarantool-patches] [PATCH v2 1/2] box: speed up tuple_field_map_create

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

Hi! Thanks for the patch!

On 30.11.2020 12:14, Serge Petrenko via Tarantool-patches wrote:
> Since the introduction of JSON path indices tuple_init_field_map, which
> was quite a simple routine traversing a tuple and storing its field data
> offsets in the field map, was renamed to tuple_field_map_create and
> optimised for working with JSON path indices.
> 
> The main difference is that tuple format fields are now organised in a
> tree rather than an array, and the tuple itself may have indexed fields,
> which are not plain array members, but rather members of some sub-array
> or map. This requires more complex iteration over tuple format fields
> and additional tuple parsing.
> 
> All the changes were, however, unneeded for tuple formats not supporting
> fields indexed by JSON paths.
> 
> Rework tuple_field_map_create so that it doesn't go through all the
> unnecessary JSON path-related checks for simple cases and restore most
> of the lost performance.
> 
> Below are some benchmark results for the same workload that pointed to
> the degradation initially.
> Snapshot recovery time on RelWithDebInfo build for a 1.5G snapshot
> containing a single memtx space with one secondary index over 4 integer
> and 1 string field:
> 
>         Version            | Time (s) | Difference relative to 1.10
> ---------------------------|----------|----------------------------
> 1.10 (the golden standard) |    28    |             -/-
> 2.x (degradation)          |    39    |            + 39%
> 2.x (patched)              |    31    |            + 11%
> 
> Profile shows that the main difference is in memtx_tuple_new due to
> tuple_init_field_map/tuple_field_map_create performance difference.
> 
> Numbers below show cumulative time spent in tuple_init_field_map (1.10) /
> tuple_field_map_create (unpatched) / tuple_field_map_create (patched).
> 2.44 s / 8.61 s / 3.19 s
> 
> More benchmark results can be seen at #4774
> 
> Part of #4774
> 
> wip. optimisation.

You may want to delete the last sentence.

Other than that, looks good.