|
Am 09.01.2018 um 00:26 schröbte Paige DePol:
Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:One thing I am curious about, Roberto, is the creation of tables to hold the vargs. Won't this add significant overhead for the table allocations vs just leaving the vargs on the stack?That was the motivation for stack varargs. But "significant" is quite relative. Moreover, stack varargs add an overhead (a quite small one, but it is not zero) to all functions, even those not varargs. We do not see vararg functions in critical paths often. Several (most?) vararg functions have to create tables (or pay the price of 'select') anyway. More important, table is the bread-and-butter of Lua. If we start to demonise them, we are left with little else. -- RobertoVery good point about tables, Roberto! I would guess that anyone looking for performance probably wouldn't be using varargs on critical paths anyway.
Or resort to C for avoiding the extra memory allocation (or addressing other performance concerns).
One other thing I wanted to point out (which is related to the array discussion in another thread):
I find it unfortunate that Lua needs two different array implementations in its tiny standard library -- one convenient but limited one (sequences), and a more powerful but inconvenient one (vararg tables). Now it looks like both implementations will even end up in the Lua core. Since we apparently can't agree on a single implementation that will cover all needs, may I propose that the table library also work for vararg tables in addition to sequences? It seems strange that the inconvenient array type doesn't have any support functions in the standard library, and especially inserting or removing elements are things you might want to do to vararg tables.
Philippp.s.: If the concept of n fields of vararg tables ends up in the Lua core, the length operator could (raw-)inspect n as well. Maybe in time most Lua code would be able to handle both array types without extra effort. But that is a proposal for another time.