From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 702E945C304 for ; Wed, 2 Dec 2020 01:01:43 +0300 (MSK) References: From: Vladislav Shpilevoy Message-ID: <245a5084-7f35-ea9c-6259-a7d260b300a0@tarantool.org> Date: Tue, 1 Dec 2020 23:01:41 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v2 1/2] box: speed up tuple_field_map_create List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko , korablev@tarantool.org Cc: tarantool-patches@dev.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.