 |
lua-l archive |
|
|
||
|
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/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/src/globals.c#L194
https://github.com/spc476/mod_blog/blob/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/src/globals.c#L496
https://github.com/spc476/mod_blog/blob/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/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.