Re: [Tarantool-patches] [PATCH 1/1] json: use cord_ibuf for encoding and decoding

[Oleg Babin via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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
> AFAIK.

No, pcall in Lua is jitted (see 
http://wiki.luajit.org/NYI#libraries_base-library).

But anyway I agree it gives huge overhead on hot paths.