[Tarantool-patches] [PATCH 1/1] fiber: extend max fiber name length to 255

[Vladislav Shpilevoy]

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.