From: Alexander Turenko <alexander.turenko@tarantool.org> To: Leonid <lvasiliev@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI) Date: Thu, 12 Dec 2019 01:21:35 +0300 [thread overview] Message-ID: <20191211222134.swzcqcbpn4tbg64m@tkn_work_nb> (raw) In-Reply-To: <156ce93b495648d6f3fd6c879b0d9aaf56754a1e.1574773773.git.lvasiliev@tarantool.org> Kostya, thanks for bringing the FFI / Lua-C question into our view. ---- We decided to don't change existing convention: let's use FFI when possible and Lua-C API for functions that access a Lua state somehow (including touching tarantool_L, yielding and running triggers / callbacks). The core reason is that FFI allows to produce longer JIT traces that should positively impact performance of an application at whole. We have no good understanding how performant Lua-C API with trace stitching, however simple benchmarks (shared by Leonid) shows positive impact of using FFI calls. We have no interpretation for those benchmarks for now. Whether Lua-C runs were JITed at all? Whether a result will be different if there will be more JITable code around? So for now things looks just as 'FFI is faster the Lua-C'. Hope we'll investigate this later. We need to find a way to reduce probability that a function that is called via ffi (or one that is called from it) will be changed in a future and starts to yield or touch a Lua state. We should look whether we can mark functions that are called from ffi (see also [1]) and all its callee to at least verify ourself when changing code. Also we can work on detection of so called ffi sandwitches and doing more stress testing. It seems that both directions are worth to dig into. [1]: https://github.com/tarantool/tarantool/issues/4202 ---- Back to the patch. Since we'll just move one function, I would not perform refactoring I proposed initially: don't move all related functions together. Let's rewrite box.rollback_to_savepoint() using Lua-C API and place it together with box.commit() and box.rollback() to src/box/lua/init.c. I think we don't need any pure Lua wrapper around this function: we can access a Lua table field and raise an error just from C, so I don't see a reason to split a function logic around two files (src/box/lua/schema.lua and src/box/lua/init.c). They are both about API we expose to Lua. WBR, Alexander Turenko. On Tue, Nov 26, 2019 at 04:13:43PM +0300, Leonid wrote: > https://github.com/tarantool/tarantool/issues/4427 > https://github.com/tarantool/tarantool/tree/lvasiliev/gh-4427-move-some-stuff-from-ffi-to-c-api > > --- > src/box/CMakeLists.txt | 2 + > src/box/lua/init.c | 4 + > src/box/lua/schema.lua | 71 ----------------- > src/box/lua/txn.c | 145 +++++++++++++++++++++++++++++++++++ > src/box/lua/txn.h | 49 ++++++++++++ > src/box/lua/txn.lua | 53 +++++++++++++ > src/box/txn.c | 2 + > test/box/misc.result | 1 + > test/engine/savepoint.result | 12 +-- > 9 files changed, 262 insertions(+), 77 deletions(-) > create mode 100644 src/box/lua/txn.c > create mode 100644 src/box/lua/txn.h > create mode 100644 src/box/lua/txn.lua > --- box.commit yields, so it's defined as Lua/C binding > --- box.rollback yields as well Let's move box.rollback_to_savepoint() to them.
next prev parent reply other threads:[~2019-12-11 22:21 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-26 13:13 Leonid 2019-11-26 21:05 ` Konstantin Osipov 2019-11-26 21:17 ` Alexander Turenko 2019-11-27 8:31 ` Konstantin Osipov 2019-11-28 8:10 ` Leonid Vasiliev 2019-11-28 12:34 ` Konstantin Osipov 2019-11-28 13:00 ` Igor Munkin 2019-11-28 13:18 ` Konstantin Osipov 2019-11-28 14:03 ` Igor Munkin 2019-11-28 15:58 ` Konstantin Osipov 2019-11-28 18:36 ` Igor Munkin 2019-11-29 5:30 ` Konstantin Osipov 2019-11-29 17:43 ` Igor Munkin 2019-11-29 5:41 ` Konstantin Osipov 2019-11-29 17:37 ` Igor Munkin 2019-12-04 13:05 ` Leonid Vasiliev 2019-12-04 13:15 ` Konstantin Osipov 2019-12-05 8:27 ` Leonid Vasiliev 2020-03-20 18:48 ` Igor Munkin 2020-03-20 19:27 ` Konstantin Osipov 2019-12-11 22:21 ` Alexander Turenko [this message] 2019-12-12 8:23 ` Leonid Vasiliev 2020-01-15 17:05 ` Alexander Turenko 2019-12-12 8:49 ` Konstantin Osipov
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=20191211222134.swzcqcbpn4tbg64m@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=lvasiliev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI)' \ /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