[patches] [PATCH 3/4] tuple: check key for sequential parts on compile time

v.shpilevoy at tarantool.org v.shpilevoy at tarantool.org
Sat Feb 17 23:35:34 MSK 2018


I did not measure it with benches. But obviously removal these cycles on compile time is faster, than ‘for’s in each extracter.

С уважением, Владислав Шпилевой.

> 17 февр. 2018 г., в 22:03, Vladimir Davydov <vdavydov.dev at gmail.com> написал(а):
> 
>> On Tue, Feb 13, 2018 at 06:28:37PM +0300, Vladislav Shpilevoy wrote:
>> --- a/src/box/tuple_extract_key.cc
>> +++ b/src/box/tuple_extract_key.cc
>> @@ -57,6 +57,7 @@ tuple_extract_key_sequential(const struct tuple *tuple,
>>  * General-purpose implementation of tuple_extract_key()
>>  * @copydoc tuple_extract_key()
>>  */
>> +template <bool contains_sequential_parts>
>> static char *
>> tuple_extract_key_slowpath(const struct tuple *tuple,
>>               const struct key_def *key_def, uint32_t *key_size)
>> @@ -73,17 +74,21 @@ tuple_extract_key_slowpath(const struct tuple *tuple,
>>            tuple_field_raw(format, data, field_map,
>>                    key_def->parts[i].fieldno);
>>        const char *end = field;
>> -        /*
>> -         * Skip sequential part in order to minimize
>> -         * tuple_field_raw() calls.
>> -         */
>> -        for (; i < key_def->part_count - 1; i++) {
>> -            if (key_def->parts[i].fieldno + 1 !=
>> -                key_def->parts[i + 1].fieldno) {
>> -                /* End of sequential part */
>> -                break;
>> +        if (contains_sequential_parts) {
>> +            /*
>> +             * Skip sequential part in order to
>> +             * minimize tuple_field_raw() calls.
>> +             */
>> +            for (; i < key_def->part_count - 1; i++) {
>> +                if (key_def->parts[i].fieldno + 1 !=
>> +                    key_def->parts[i + 1].fieldno) {
>> +                    /*
>> +                     * End of sequential part.
>> +                     */
>> +                    break;
>> +                }
>> +                mp_next(&end);
> 
> In comparison to tuple_field_raw(), which is called on each iteration,
> the cost of the loop you're optimizing out should be negligible. Is it
> really worth it? Did you run any tests that showed a performance gain?




More information about the Tarantool-patches mailing list