Why sol2 is slower than LuaBridge3?

[Alterise]

I've done some benchmarks. For some reason sol2 perform slower than LuaBridge3. In sol2 repo I found benchmarks showing that sol2 have to outperform LuaBridge3, but for some reason on real use cases it's not.

Am I doing something wrong?

Sol2 benchmark:

Performing Sol3 Benchmark:
Time elapsed (Increment (Lua)): 225.012ms
Time elapsed (Increment (C++)): 210.341ms

Time elapsed (String Argument (Lua)): 400.203ms
Time elapsed (String Argument (C++)): 241.732ms

Time elapsed (String Const Argument (Lua)): 405.579ms
Time elapsed (String Const Argument (C++)): 267.502ms

Time elapsed (String View Argument (Lua)): 321.18ms
Time elapsed (String View Argument (C++)): 258.553ms

Time elapsed (String Char Argument (Lua)): 311.116ms
Time elapsed (String Char Argument (C++)): 244.752ms

Time elapsed (String Iterator (Lua)): 561.75ms
Time elapsed (String Iterator (C++)): 188.024ms

Time elapsed (String Const Iterator (Lua)): 555.881ms
Time elapsed (String Const Iterator (C++)): 215.2ms

Time elapsed (String View Iterator (Lua)): 462.316ms
Time elapsed (String View Iterator (C++)): 205.954ms

Time elapsed (String Char Iterator (Lua)): 456.837ms
Time elapsed (String Char Iterator (C++)): 197.267ms

Time elapsed (String Internal Iterator (Lua)): 28.6687ms

Time elapsed (Class passing (Lua)): 491.857ms
Time elapsed (Class Passing (C++)): 188.96ms

Time elapsed (Class Getting (Lua)): 444.842ms
Time elapsed (Class Getting (C++)): 87.885ms

Time elapsed (Class method call (Base Class)): 1018.63ms
Time elapsed (Class method call (Derived Overwritten Class)): 950.832ms
Time elapsed (Class method call (Derived Not Overwritten Class)): 1672.24ms

Time elapsed (Class field access (Base Class)): 837.028ms
Time elapsed (Class field access (Derived Class)): 1512.29ms

LuaBridge3 benchmark:

Performing LuaBridge3 Benchmark:
Time elapsed (Increment (Lua)): 85.4452ms
Time elapsed (Increment (C++)): 685.158ms

Time elapsed (String Argument (Lua)): 187.733ms
Time elapsed (String Argument (C++)): 711.398ms

Time elapsed (String Const Argument (Lua)): 191.785ms
Time elapsed (String Const Argument (C++)): 740.246ms

Time elapsed (String View Argument (Lua)): 149.068ms
Time elapsed (String View Argument (C++)): 725.589ms

Time elapsed (String Char Argument (Lua)): 118.564ms
Time elapsed (String Char Argument (C++)): 718.35ms

Time elapsed (String Iterator (Lua)): 255.276ms
Time elapsed (String Iterator (C++)): 728.269ms

Time elapsed (String Const Iterator (Lua)): 257.562ms
Time elapsed (String Const Iterator (C++)): 756.581ms

Time elapsed (String View Iterator (Lua)): 194.296ms
Time elapsed (String View Iterator (C++)): 738.581ms

Time elapsed (String Char Iterator (Lua)): 170.795ms
Time elapsed (String Char Iterator (C++)): 737.091ms

Time elapsed (String Internal Iterator (Lua)): 5.10969ms

Time elapsed (Class passing (Lua)): 141.677ms
Time elapsed (Class Passing (C++)): 489.28ms

Time elapsed (Class Getting (Lua)): 205.569ms
Time elapsed (Class Getting (C++)): 507.022ms

Time elapsed (Class method call (Base Class)): 154.02ms
Time elapsed (Class method call (Derived Overwritten Class)): 155.294ms
Time elapsed (Class method call (Derived Not Overwritten Class)): 248.309ms

Time elapsed (Class field access (Base Class)): 181.451ms
Time elapsed (Class field access (Derived Class)): 283.496ms

[Rochet2]

Suspicious that the lua benchmarks are also slower. I see that you have #define SOL_ALL_SAFETIES_ON 1 Have you tried to disable safeties? It is possible that sol does additional checks for numeric values compared to luabridge when safeties are on that then slow down. I would guess that is where the overhead for Increment benchmark comes from.

As an example, for sol with all safeties on, passing 1.5 to a function that takes an int is an error, while that may not be an error for luabridge.

https://godbolt.org/z/r7ov397MP

[patlecat]

Suspicious that the lua benchmarks are also slower. I see that you have #define SOL_ALL_SAFETIES_ON 1 Have you tried to disable safeties? It is possible that sol does additional checks for numeric values compared to luabridge when safeties are on that then slow down. I would guess that is where the overhead for Increment benchmark comes from.

As an example, for sol with all safeties on, passing 1.5 to a function that takes an int is an error, while that may not be an error for luabridge.

https://godbolt.org/z/r7ov397MP

BTW using GCC 11.1 fails to compile your example, does SOL2 not compile with it?

[Rochet2]

BTW using GCC 11.1 fails to compile your example, does SOL2 not compile with it?

There is a missing #include <limits>. This is true for the version godbolt is using (v3.2.1) and the latest v3.2.2 release. Adding the include before the sol header will fix the issue. The issue has been fixed in https://github.com/ThePhD/sol2/commit/e5e6466e09b632677d24a8f204d6a0ea0a8862b1 and is a part of v3.2.3 which tagged but not released like v3.2.2 is.