My assumptions are much simpler: If a C operation has a direct Lua equivalent, then the Lua equivalent has "reasonable" performance.
Every function in the table library uses operations that are available in Lua as well, either as functions or as built-in operations. The only two exceptions are `table.concat` (which uses the buffer API), and `table.unpack` (which uses the Lua stack to create a return value list).
The only operation for concatenating strings in Lua is `..` which creates lots of temporaries. There has been a Lua buffer module by Roberto which uses some logarithmic tricks to avoid many of those temporaries, but this is still a lot easier and more efficient if you have writable buffers like in C.
The same is true for `table.unpack`. In C you just push the table elements onto the stack and return the number of elements, while in Lua you have to assemble the return value list via recursive function calls. This is because the available operations on vararg lists are very limited in Lua.
So I have valid (hopefully) reasons for `table.concat` and `table.unpack` to be implemented in C. What are the reasons for the other table functions?
I’m nor sure what you would define as “reasonable”, but I see no validity in that assumption. Looking at the current table library…
setmetatable() / getmetatable() — Cannot have a Lua equivalent.
table.insert() / table.remove() — While it’s easy to construct Lua functions that have equivalent functionality, I cannot see how you can argue that Lua could ALWAYS have “reasonable” performance when compared to C .. what if the table implementation changes to use (say) a red/black tree, which has vastly different performance characteristics?
table.sort() — This is possibly the ONLY candidate that could be coded reasonably in Lua, though in practical terms I would doubt if it could be done without consuming considerably more real-world memory.
pair/ipairs/concat/pack/unpack have already been discussed.
So, my conclusion is very LITTLE of the existing table API warrants re-coding as Lua.
—Tim
