From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id D7DAA6FC8B; Tue, 12 Oct 2021 00:50:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D7DAA6FC8B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1633989012; bh=M8/ZUjUSxhZMnr/0xWwqmiIVzsXL1t4UG3MfgCGZsR0=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=DhrTzB7Tpc0djWgTvU1VuK8j1Kjk5zSXqX3Lh6etDcplEo1OJisM+R92nDNXeWGZf qc6Hgd2zJ7tFldpR6ZGYDclID5paYG0nqrYrgqc82lXUn57LG+81OE4PzX3LB8NV/5 LtAEIC7Es4tho18kUC/BYJHdYMpPe6tWUbArxCeM= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [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 1A22A6FC8B for ; Tue, 12 Oct 2021 00:50:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1A22A6FC8B Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1ma3BR-0006Bn-76; Tue, 12 Oct 2021 00:50:09 +0300 Message-ID: <797b7cc5-800a-69a2-0d4d-51727d0a5607@tarantool.org> Date: Mon, 11 Oct 2021 23:50:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org References: <7447231b-f112-5228-ebaa-40a93f62aefa@tarantool.org> <20211005093250.GC55311@tarantool.org> In-Reply-To: <20211005093250.GC55311@tarantool.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD922964B4BA091D9AC46E470C2D58396F8D075BACE03C67103182A05F5380850406E02A34FBE14965D41346AC1E49318453F6F4583200D6068FDF3279743FB47C2 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7EB05B7739F1E6D56EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063727BBC20C3D5F36038638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D85E5CBFAFA2F2E3A529887FEBC563D9DF117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC292D688DDAD4E7BC389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC8744B801E316CB65FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A213B5FB47DCBC3458834459D11680B50559325BC3F25EBEA278EFF000B2A2BE86 X-C1DE0DAB: 0D63561A33F958A5731DBBD3342EE9AC66AEED14ECC68EBEB0B4F9945DDB0F88D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA759D2A03B9C34326B3410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3498EF79680EE3725CC249BF413DEF62E00A26B7442218973873F64F112DB4FF24521A74BFFDF5C5DF1D7E09C32AA3244C3F1CB233BC7D52331A5262D60346F2B2CE0B41342B755BCD729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioju/+AAevgYAXmkrKwbKOh+A== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D06F67AAD92C60223C8A32D6DAF858C673841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v4 06/16] sql: introduce mem_append() X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi! Thanks for the fixes! >>> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c >>> index 079083fa1..b8ead8f41 100644 >>> --- a/src/box/sql/mem.c >>> +++ b/src/box/sql/mem.c >>> @@ -1925,6 +1925,27 @@ mem_move(struct Mem *to, struct Mem *from) >>> from->zMalloc = NULL; >>> } >>> >>> +int >>> +mem_append(struct Mem *mem, const char *value, uint32_t len) >>> +{ >>> + assert((mem->type & (MEM_TYPE_BIN | MEM_TYPE_STR)) != 0); >>> + if (len == 0) >>> + return 0; >>> + int new_size = mem->n + len; >>> + if (((mem->flags & (MEM_Static | MEM_Dyn | MEM_Ephem)) != 0) || >>> + mem->szMalloc < new_size) { >>> + /* >>> + * Force exponential buffer size growth to avoid having to call >>> + * this routine too often. >>> + */ >>> + if (sqlVdbeMemGrow(mem, new_size + mem->n, 1) != 0) >> >> Looks like you could call sqlVdbeMemGrow() without all these checks >> above. The grow function does them already. >> > True, fixed. There is a case where the behavior will be different - I > mean the case where new_size < szMalloc and new_size + n > szMalloc, > but that doesn't seem to be a very common case. Wait, this does not look correct either. I thought sqlVdbeMemGrow() does the exponential grow. But if it does not, we need to either patch it, or keep some checks above. The 'standard' way is to grow only when necessary, but at least x2. How this new way works I can't tell. It might be worse. You will always have unused free space. Lets either stick to the old way or patch the grow function.