Re: Binding Libraries: A (Performance) Comparison

[Tim Hill <drtimhill@...>]

On Jul 29, 2016, at 5:17 PM, ThePhD <jm3689@columbia.edu> wrote:

Hey Everyone,

     I'm one of the authors of a wrapper library, sol2. I finally finished creating and running and comprehensive benchmark suite on several C/C++ <-> Lua wrapper libraries (including the plain C API) and I wanted to share the results here, seeing as every now and then people mention the performance of wrapper libraries and raise questions as to their efficacy.

     They can be found here: http://sol2.readthedocs.io/en/latest/benchmarks.html ( code for them lives here: https://github.com/ThePhD/lua-bench ).

     What I've found so far is that in many cases wrapper libraries can reach the efficiency of the plain C API, while providing rather neat abstractions over the underlying C code that are often easier to reuse.... For a certain defition of "neat abstractions" (some of them are fairly verbose, others a bit more slim).

     Has anyone else had any experience with binding libraries? Have they been hindrances or helpful? Was performance ever an issue for your domain? I'm curious about the experience for others outside of my userbase.

Sincerely,

ThePhD

There is a school of thought here that the best wrapper library is always thin; that is, it simply converts the underlying C API 1:1 into Lua, with minimal mapping of data types as necessary. I presume the assumption is that the less C code there is the less buggy the code will be (which seems to assume the Lua code will be less buggy), and that users of the C library will be familiar with the API and therefore can re-use their knowledge in Lua. I also suspect another reason is to avoid writing documentation for a new API.

I don’t subscribe to this philosophy. Lua has different paradigms and assumptions to C, and there is often an impedance mis-match between the C library structure and Lua idioms. Also, calling many C functions and then processing radish data in Lua seems to me rather inefficient. When we wrap C libraries here we always think hard about presenting the API in as Lua-like a manner as possible, even if that means changing the shape of the API significantly. Finally, I’m not clear how many Lua developers are comfortable with C and therefore would already have knowledge of the underlying library (or even be able to understand it).

For example, our SQLite wrapper library really comes down to 4 APIs in Lua: open(), close(), compile() and execute(). The execute() API takes care of running any compiled SQLite statement, with all table rows converted to/from Lua tables, and uses an engine that automatically iterates over multiple rows (again, represented as a Lua table or rows). In general, this means about 1/2 to 1/10 the amount of Lua code to access databases, and is much faster than thinner wrappers (it’s a long time since we tested them, but the overhead was about 8x less than a thin library). We also run the engine asynchronously allowing Lua to perform other processing while the database transaction completes.

—Tim