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:
> 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
The only comment I have about this is that modification of the "path
string" is not required. I wrote code  that does traverse a "path string"
without modifying the string at all . Yes, this is slower than using a
simple string literal to lua_getfield()  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)
blog/blob/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/src/globals.c#L194
blog/blob/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/src/globals.c#L496
blog/blob/ 9fcfdcae480c0fc22389543a2d4379 e5e9e2c0a5/src/globals.c#L470
 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).
 Or other API calls that retrieve data from a table.