[Tarantool-patches] [PATCH 0/1] fix box.info:memory()
Igor Munkin
imun at tarantool.org
Thu Jul 16 21:16:58 MSK 2020
Sasha,
Thanks for your explanation!
On 09.07.20, Alexander Turenko wrote:
<snipped>
> >
> > I have no idea why it is implemented in such complex way, maybe Sasha
> > does? Why box.info.memory yields an empty "callable" table on each
> > lookup? Why it can't just return a function to be called or a table with
> > memory metrics as a result of the lookup? Unfortunately the latter
> > approach breaks the backward compatibility but the first one can save
> > some time on short-term objects creation (I guess no one checks
> > box.info.memory type). Thoughts? Please also consider the comments I
> > left for the patch itself.
>
> I don't see a reason. The history of src/box/lua/info.c changes shows
> that this way was initially implemented for box.info.phia() (which was
> renamed later to box.info.vinyl()). Then box.info.memory(),
> box.info.gc() and box.info.sql() were added in the same way.
> box.info.phia() was moved from box.phia().
>
> I agree with you. We should define a case to estimate impact of
> replacing a table + metamethod with a function. Not even to make a
> decision whether it worth to change, but to imagine the situation at
> whole.
>
> I would consider metrics collection case using tarantool/metrics every
> minute when default metrics are enabled. I guess it'll call
> box.info.vinyl(), box.info.memory() and box.info.gc() once for each
> metrics collection. So the proposed change will safe 3 extra short-term
> object creations per minute.
>
> I don't see a case when those functions should be called more often and
> become a part of hot path. So I would say that reducing of GC object
> allocations here does not look worthful for me considering possible
> impact of subtle differences (like serialization of `box.info` or other
> differences we can miss) that may fail some scripts or tools.
Yes, it's definitely not a part of the hot path, *but* still implicitly
affects the platform performance a little. Maybe we need to file an
issue for such investigation? It would be nice to look on this part
under the particular workload.
>
<snipped>
--
Best regards,
IM
More information about the Tarantool-patches
mailing list