 |
lua-l archive |
|
|
||
|
Am 28.11.2013 00:06 schröbte Tim Hill:
On Nov 27, 2013, at 1:11 PM, Philipp Janda <siffiejoe@gmx.net> wrote:4. Everything except 'sort' can be done (almost) as efficiently (and to taste) in Lua. It would be useful to have 'sort' surfaced in the C API as well as a Lua library function.What makes `table.sort` different? Certainly you can implement an efficient sort routine in Lua (and it has been done before[1]). I'd say `table.unpack` and maybe `table.concat` are the only functions in the table library deserving a C implementation.I really don’t agree with this, as I think it is based upon two false assumptions: (a) the ratio between Lua code performance and C code performance is pretty much the same across different platforms/architectures, and (b) the internal implementation of tables is fixed and well-known.
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?
[...] —Tim
Philipp