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.

lua_binding_benchmarks by satoren (developer of kaguya) (sol is the “sol3” entry)

lua-bindings-shootout by ThePhD (developer of sol)

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.