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 1DB976EC60; Sun, 28 Feb 2021 20:36:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1DB976EC60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614533776; bh=Yr14JP2bTEg63Y4BvMumUsQzi8Qe/ST7uWPcwgD/yQc=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=fvf7CyBkUkbfTLZP0JsMieRzLQwJTTBmpfnP3sEdVFXEBfW7rPPKl/rH0YfS+9vym DKNfJIC/xUHCrS8214f63p674akEQmU4csW9v+thOfL7IVAoudXnLzXuhiB+gb7d5E txgkDgmFFDmyesTX+9ghzPHYgEEwvsIwc+JNzplk= Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 2D33970157 for ; Sun, 28 Feb 2021 20:35:45 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2D33970157 Received: by smtpng2.m.smailru.net with esmtpa (envelope-from ) id 1lGPyq-0005YV-5y; Sun, 28 Feb 2021 20:35:44 +0300 To: Timur Safin , imeevma , Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org References: <048e01d6fec9$1b363fb0$51a2bf10$@tarantool.org> Message-ID: <157b1167-ec63-5214-cac3-388ee829b151@tarantool.org> Date: Sun, 28 Feb 2021 18:35:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <048e01d6fec9$1b363fb0$51a2bf10$@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9795828B892398B728FC1D9EEA0F34691023F7D12248569F7182A05F538085040C79302C66BA4AA9BC1E0C4768B66CCAE5B27A24C10C27FE4537D666027710A1E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE776278210742627ABEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637E80306D42697F3998638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCE4AC53B8EBFE911DDFEBDC12808B938DAFDC4A677F35A982389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0ECC8AC47CD0EDEFF8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6F459A8243F1D1D44CC7F00164DA146DA6F5DAA56C3B73B23C77107234E2CFBA567F23339F89546C55F5C1EE8F4F765FC9F5955FECEF5819E75ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E73528A6D463EDFD0DBBC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F347543BADC64E7283B503F486389A921A5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A51AD04E4DCEE5E02B737D30D1CB9E0CFB8DE67FE36E9162F1D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75968C9853642EB7C3410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D1AE09A115117C96EED618321AC0040EF371F8CAB86AB395DC07CA36761767BA2131CD3F8904C9731D7E09C32AA3244CD42FB38BA6E18CA3BCF6654AD40873D9D08D48398F32B4A6927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojlGyyJLC51G+J/cyTKp55xw== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822DED19B7C2DE12F26BDA9864791FB83D63841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] FW: [PATCH v1 09/10] sql: refactor vdbeaux.c 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" > : @@ -1402,41 +1408,26 @@ sqlVdbeList(Vdbe * p) > : mem_set_i64(pMem, pOp->p3); > : pMem++; > : > : - if (sqlVdbeMemClearAndResize(pMem, 256)) { > : - assert(p->db->mallocFailed); > : - return -1; > : - } > : - pMem->flags = MEM_Str | MEM_Term; > : - zP4 = displayP4(pOp, pMem->z, pMem->szMalloc); > : - > : - if (zP4 != pMem->z) { > : - pMem->n = 0; > : - sqlVdbeMemSetStr(pMem, zP4, -1, 1, 0); > : - } else { > : - assert(pMem->z != 0); > : - pMem->n = sqlStrlen30(pMem->z); > : - } > : + size_t size = 256; > : + char *tmp_buf = (char *) static_alloc(size); > : + assert(tmp_buf != NULL); > : + zP4 = displayP4(pOp, tmp_buf, size); > : + mem_set_str(pMem, zP4, strlen(zP4), 0, true); > : pMem++; > > Please, please, not introduce any newer usage of static_alloc, > it's very fragile and might work only inside of controlled context of > single module (i.e. swim). If used by multiple modules - > results are unpredictable. Any other allocator is fine if used > by multiple fibers, but not static_alloc. What exactly is the problem with static alloc here? Can you explain? >From the text above I can only see one argument - 'fragile'. Which is not a real argument. Static alloc is faster than anything we have except allocation on the stack. So I would prefer to use it when possible.