Benchmark Bindings

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Benchmark Bindings

ThePhD
I realize that I had not posted this to the list just yet. I did some work previously and presented the benchmarks at Lua Workshop 2016. There were some derps in the benchmarks and some other libraries people wanted to see in the benchmarks. I reworked nearly everything and created a new repository with a new CMake-based build so it could be run on other platforms than Windows.

Here's the writeup of the new benchmarks and how I did it, as well as some (minor) insights into how someone would typically use the C API versus what would be the most performant way of doing it: https://thephd.github.io/2018/05/17/Lua-Bindings-Shootout.html

I hope it helps a few people here!
Reply | Threaded
Open this post in threaded view
|

Re: Benchmark Bindings

Sean Conner
It was thus said that the Great ThePhD once stated:
>
> Here's the writeup of the new benchmarks and how I did it, as well as some
> (minor) insights into how someone would typically use the C API versus what
> would be the most performant way of doing it:
> https://thephd.github.io/2018/05/17/Lua-Bindings-Shootout.html
>
> I hope it helps a few people here!

  I'm reading your writeup, and I came across this:

> A few libraries here also make a curious choice: rather than making you pass
> separate null-terminated strings to dive into nested tables, it instead
> writes a tiny little parser to handle every "." that appears in the strings
> you provide. This means you can access nested tables with "a.b.c", but the
> problem becomes that it has to in-place edit the strings you pass to
> null-terminate, perform the lookup for the next ?chunk?, and then continue
> processing the string. It?s not ideal and it does incur a performance hit,
> so while super convenient to specify a path in a single string, it is not
> advisable.

  The only comment I have about this is that modification of the "path
string" is not required.  I wrote code [1] that does traverse a "path string"
without modifying the string at all [2].  Yes, this is slower than using a
simple string literal to lua_getfield() [3] so it should be avoided when you
can, but to say you have to modify the string is erroneous.

  -spc (It's just a minor detail really)

[1] https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L194
        https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L496
        https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L470

[2] Since most, if not all, of the strings I'm passing in are C literal
        constant strings, which can't be modified (at least on the platforms
        I run on).

[3] Or other API calls that retrieve data from a table.

Reply | Threaded
Open this post in threaded view
|

Re: Benchmark Bindings

ThePhD
Thank you for pointing that out! You're right that it's not the only implementation: I corrected that paragraph. Still, both cases cause a drop in performance, so it's certainly something to keep noted in the article.

On Sun, Jun 17, 2018 at 5:05 PM, Sean Conner <[hidden email]> wrote:
It was thus said that the Great ThePhD once stated:
>
> Here's the writeup of the new benchmarks and how I did it, as well as some
> (minor) insights into how someone would typically use the C API versus what
> would be the most performant way of doing it:
> https://thephd.github.io/2018/05/17/Lua-Bindings-Shootout.html
>
> I hope it helps a few people here!

  I'm reading your writeup, and I came across this:

> A few libraries here also make a curious choice: rather than making you pass
> separate null-terminated strings to dive into nested tables, it instead
> writes a tiny little parser to handle every "." that appears in the strings
> you provide. This means you can access nested tables with "a.b.c", but the
> problem becomes that it has to in-place edit the strings you pass to
> null-terminate, perform the lookup for the next ?chunk?, and then continue
> processing the string. It?s not ideal and it does incur a performance hit,
> so while super convenient to specify a path in a single string, it is not
> advisable.

  The only comment I have about this is that modification of the "path
string" is not required.  I wrote code [1] that does traverse a "path string"
without modifying the string at all [2].  Yes, this is slower than using a
simple string literal to lua_getfield() [3] so it should be avoided when you
can, but to say you have to modify the string is erroneous.

  -spc (It's just a minor detail really)

[1]     https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L194
        https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L496
        https://github.com/spc476/mod_blog/blob/9fcfdcae480c0fc22389543a2d4379e5e9e2c0a5/src/globals.c#L470

[2]     Since most, if not all, of the strings I'm passing in are C literal
        constant strings, which can't be modified (at least on the platforms
        I run on).

[3]     Or other API calls that retrieve data from a table.


Reply | Threaded
Open this post in threaded view
|

Re: Benchmark Bindings

Andrew Starks-2
In reply to this post by ThePhD


On Sun, Jun 17, 2018 at 6:43 AM, ThePhD <[hidden email]> wrote:
I realize that I had not posted this to the list just yet. I did some work previously and presented the benchmarks at Lua Workshop 2016. There were some derps in the benchmarks and some other libraries people wanted to see in the benchmarks. I reworked nearly everything and created a new repository with a new CMake-based build so it could be run on other platforms than Windows.

Here's the writeup of the new benchmarks and how I did it, as well as some (minor) insights into how someone would typically use the C API versus what would be the most performant way of doing it: https://thephd.github.io/2018/05/17/Lua-Bindings-Shootout.html

I hope it helps a few people here!

I read through your write up. Thank you for doing such a thorough job and creating something so useful. I hope that it continues to be updated as necessary.

Also, this makes me wish I had seen this and known about Sol. 

--
Andrew Starks