From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 B37084765E0 for ; Fri, 25 Dec 2020 13:39:24 +0300 (MSK) References: <810f25cf-1c5e-3358-2050-4b0ce2f6ece4@tarantool.org> From: Sergey Nikiforov Message-ID: Date: Fri, 25 Dec 2020 13:39:22 +0300 MIME-Version: 1.0 In-Reply-To: <810f25cf-1c5e-3358-2050-4b0ce2f6ece4@tarantool.org> 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: Leonid Vasiliev , tarantool-patches@dev.tarantool.org Cc: Vladislav Shpilevoy 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. > 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.