[Tarantool-patches] [PATCH 1/1] json: use cord_ibuf for encoding and decoding
olegrok at tarantool.org
Mon May 24 19:00:34 MSK 2021
Thanks for your explanation. LGTM.
I put several comments below.
On 24.05.2021 18:49, Vladislav Shpilevoy wrote:
> Hi! Thanks for the review!
> On 24.05.2021 12:04, Oleg Babin wrote:
>> Hi! Thanks for your patch.
>> I see strange effect. After a patch following script:
>> for i = 1, 1e9 do pcall(json.encode, function() end) end
>> produces quite strange effects with memory. After some time
>> my system kills a process - also I see in htop that process consumes about 20% of memory.
>> In contrast before the patch process uses 0.1% of memory and doesn't have any oscillations
>> in "VIRT" and "RES" columns. Yes, it's a negative case but I believe such behaviour shouldn't be affected as well.
> This is happening because you didn't do any yields. Cord buffer is freed
> automatically when a yield happens. This is a workaround for not being
> able to use a global buffer, which wouldn't need freeing at all.
After your explanation my comment looks irrelevant. Agree, in real projects
it's impossible to run code without any yields. Thanks!
> This is a known issue with the cord buffer, and the only working alternative
> I see is to wrap all related Lua C calls into lua_pcall(). This leads to
> perf issues for the success case, because pcall does more work; because
> you usually need to re-push the arguments; and because pcall is not jitted
No, pcall in Lua is jitted (see
But anyway I agree it gives huge overhead on hot paths.
More information about the Tarantool-patches