 |
lua-l archive |
|
|
||
|
Am 28.11.2013 03:29 schröbte Tim Hill:
On Nov 27, 2013, at 5:13 PM, Philipp Janda <siffiejoe@gmx.net> wrote: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.
Agreed, although not part of the current table library.
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 ..
As long as Lua implementation and C implementation use the same operations, and you accept my definition of "reasonable" performance, the conclusion is obvious.
what if the table implementation changes to use (say) a red/black tree, which has vastly different performance characteristics?
If you change the implementation of tables, both the Lua version and the C version of `table.insert` and `table.remove` will show a similar new performance characteristic, because both version use the same operations (`#`, `rawset`, and `rawget`). Unless you change Lua's C API and don't expose those new operations to Lua, but in that case you need a new table library anyway.
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.
Memory for the bytecode and for the debug info. What else is there? Both versions work on the same data structure (a table) ...
So, my conclusion is very LITTLE of the existing table API warrants re-coding as Lua.
Compatibility is a strong reason to keep those functions around. But they do not deserve their status as Lua standard library functions, IMHO, and I understand very well if someone decides to stay clear of the table library altogether (except `concat` and `unpack`) ...
—Tim
Philipp