From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (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 78119469719 for ; Sun, 15 Mar 2020 18:13:11 +0300 (MSK) References: <3d2907a0285c640ea09eec86c8922e43c5844953.1584198310.git.v.shpilevoy@tarantool.org> <20200314163432.GW27301@uranus> <5b4578df-aab3-968b-f9bd-a00b60bd6591@tarantool.org> <86521117-2757-a564-a9ab-5c36041dca40@tarantool.org> <20200314194837.GX27301@uranus> From: Vladislav Shpilevoy Message-ID: <3a7b227b-bf75-29b6-eb04-d5d9f2b2977b@tarantool.org> Date: Sun, 15 Mar 2020 16:13:09 +0100 MIME-Version: 1.0 In-Reply-To: <20200314194837.GX27301@uranus> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 1/1] fiber: extend max fiber name length to 255 List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tarantool-patches@dev.tarantool.org On 14/03/2020 20:48, Cyrill Gorcunov wrote: > On Sat, Mar 14, 2020 at 06:32:01PM +0100, Vladislav Shpilevoy wrote: >> Besides, most of the users don't use long names. So for them >> it would be overkill to allocate such a big name memory for each >> fiber. > > Look, currently all fiber data (including name) placed in one > continious memory area. After the patch the name gonna be "somewhere", Yeah, I know what is memory fragmentation. My point is that we don't use heap for any performance critical data. Everything in memtx is stored in slab arena. It is not affected by heap fragmentation. > moreover this "somewhere" is completely unpredictable and access > to it will cause (i'm pretty sure) useless cache drains. If we fiber name is used only in logs and in Lua. Here +1 indirect access to its name won't add even -0.00001% to total application perf. > really need to support long names then we better make some union > which would carry both, short 32 byte names or long dynamically > allocated names. Ok, we discussed that in private and agreed to use this way: 'inline' or 'hybrid' string. 32 bytes will be kept as is for short names, and longs will be allocated on the heap on demand. > And no, the statement "heap allocation doesn't affect anyone" > is simply wrong, this is not how memory works on a low level > (otherwise we wouldn't use "small" helpers at all, plain libc > malloc would fit us without a problem :). Exactly, we use 'small' for everything except long living meta such as spaces, indexes, key defs, functions, including all their names, which can be up to 65KB btw. And this meta is accessed *much* more often - on every request. And still, it is not even close to the slowest paths we have. Besides, there actually was an experiment to drop 'small' completely. And use jemalloc for all allocations. It was long time ago, when our perf was even better than now. And from what I remember we got just about -10% or so (I may be wrong, the results were not persisted anywhere). Even lower than after comparators were complicated with functional and json indexes.