benchmarks

because somebody is going to ask eventually…

Here are measurements of the overhead that libraries impose around the Lua C API: that is, the cost of abstracting / wrapping the plain Lua C API. Measurements are (at the time of writing) done with all libraries compiled against a DLL version of Lua 5.3.3 to make sure each Lua call has the same overhead between libraries (no Link Time Optimizations or other static library optimizations).

These are some informal and formal benchmarks done by both the developers of sol and other library developers / users. We leave you to interpret the data as you see fit.

As of the writing of this documentation (May 17th, 2018), sol seems to take the cake in most categories for speed! Below are some graphs from lua-bindings-shootout. You can read the benchmarking code there if you think something was done wrong, and submit a pull requests or comment on something to make sure that ThePhD is being honest about his work. All categories are the performance of things described at the top of the feature table.

Note that sol here makes use of its more performant variants (see c_call and others), and ThePhD also does his best to make use of the most performant variants for other frameworks by disabling type checks where possible as well (Thanks to Liam Devine of OOLua for explaining how to turn off type checks in OOLua).

Bars go up to the average execution time. Lower is better. Reported times are for the desired operation run through nonius. Results are sorted from top to bottom by best to worst. Note that there are error bars to show potential variance in performance: generally, same-sized errors bars plus very close average execution time implies no significant difference in speed, despite the vastly different abstraction techniques used.

bind several member functions to an object and call them in Lua code bind a variable to an object and call it in Lua code bind MANY variables to an object and access them in Lua code retrieve a C function bound in Lua and call it from C++ bind a stateful C function (e.g., a mutable lambda), retrieve it, and call it from C++ call a C function through Lua code retrieve a plain Lua function and call it from C++ return mutliple objects from C++ using std::tuple or through a library-defined mechanism return mutliple objects from C++ using std::tuple or through a library-defined mechanism and use it in Lua retrieve a value from the global table set a value into the global table measures the cost of doing consecutive lookups into a table that exists from C++; some libraries fail here because they do not do lazy evaluation or chaining properly measures the cost of retrieving a value from a table in C++; this nests 1 level so as to not be equivalent to any measured global table get optimzations measures the cost of doing consecutive lookups into a table that exists from C++ and setting the final value; some libraries fail here because they do not do lazy evaluation or chaining properly measures the cost of setting a value into a table in C++; this nests 1 level so as to not be equivalent to any measured global table set optimzations bind a C function which returns a custom class by-value and call it through Lua code retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the failure case) retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the first level success, second level failure case) retrieve an item from a table that does not exist in Lua and check for its existence (testing the cost of the success case) retrieve base class pointer out of Lua without knowing exact derived at compile-time, and have it be correct for multiple-inheritance