From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (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 053934765E0 for ; Fri, 25 Dec 2020 16:10:08 +0300 (MSK) References: <810f25cf-1c5e-3358-2050-4b0ce2f6ece4@tarantool.org> From: Leonid Vasiliev Message-ID: <99c1120f-a9ca-0098-ee7b-159e1974fd9b@tarantool.org> Date: Fri, 25 Dec 2020 16:10:02 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH v3 2/2] base64: improve decoder performance List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Nikiforov , tarantool-patches@dev.tarantool.org Cc: Vladislav Shpilevoy Hi! On 25.12.2020 13:39, Sergey Nikiforov wrote: > Hi! > > On 24.12.2020 17:08, Leonid Vasiliev wrote: >> Hi! Thank you for the patch. >> AFAIU the status of the patch is follows: >> >>  > But I see we are not going anywhere here. You don't really need LGTM >>  > from me on this patch, if you don't want to finish it. I am not >>  > strictly against these changes, because *probably* they don't add new >>  > bugs, and seem to be a tiny bit better for perf. I only don't like it >>  > being not finished. >> >> I think the changes are ok, because they are good for perf (and we have >> confirmation) and don't add degradation (our tests should guarantee >> this). >> >> See some comments below: >> >> What about a benchmark. AFAIK A. Lyapunov propose saving all benchmarks >> that we used. Did you have a conversation with him? > > Yes, I had. "perf" in tarantool. Benchmark framework is not yet merged > (https://github.com/tarantool/tarantool/tree/i.kosarev/gh-5385-tiny-tuples-with-perf-test/perf) > so I plan to commit my microbenchmark a little later to avoid duplication. > OK. >> On 22.12.2020 13:41, Sergey Nikiforov wrote: >>> Unnecessary checks were removed from internal loops. >>> Benchmark shows that performance is now ~1.19 times higher >>> (release build, Intel Core I7-9700K, only one thread). >>> --- >>> >>> Branch: >>> https://github.com/tarantool/tarantool/tree/void234/gh-3069-fix-base64-memory-overrun-v3 >>> >>> >>>   test/unit/base64.c      |  7 +++- >>>   test/unit/base64.result | 84 +++++++++++++++++++++++++++-------------- >>>   third_party/base64.c    | 36 +++++++++++++----- >>>   3 files changed, 89 insertions(+), 38 deletions(-) >>> >> >> I left my questions about the test in the review of the previous patch. > > Fixed. > >>> diff --git a/third_party/base64.c b/third_party/base64.c >>> index 3350a98ff..93442c04b 100644 >>> --- a/third_party/base64.c >>> +++ b/third_party/base64.c >>> @@ -257,10 +257,11 @@ base64_decode_block(const char *in_base64, int >>> in_len, >>>           { >>>       case step_a: >>>               do { >>> -                if (in_pos == in_end || out_pos >= out_end) >>> +                if (in_pos >= in_end) >>>                   { >>>                       state->step = step_a; >>> -                    state->result = curr_byte; >>> +                    /* curr_byte is useless now */ >>> +                    /* state->result = curr_byte; */ >> >> For multi-line comment, we use the following format: >> /* >>   * First line >>   * Second line >>   */ >> >> And leaving a commented code is not best practice. > > Fixed.