From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 1/1] fiber: extend max fiber name length to 255 Date: Sun, 15 Mar 2020 16:13:09 +0100 [thread overview] Message-ID: <3a7b227b-bf75-29b6-eb04-d5d9f2b2977b@tarantool.org> (raw) In-Reply-To: <20200314194837.GX27301@uranus> 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.
prev parent reply other threads:[~2020-03-15 15:13 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-14 15:16 Vladislav Shpilevoy 2020-03-14 16:34 ` Cyrill Gorcunov 2020-03-14 17:25 ` Vladislav Shpilevoy 2020-03-14 17:32 ` Vladislav Shpilevoy 2020-03-14 19:48 ` Cyrill Gorcunov 2020-03-15 15:13 ` Vladislav Shpilevoy [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3a7b227b-bf75-29b6-eb04-d5d9f2b2977b@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 1/1] fiber: extend max fiber name length to 255' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox