Re: Upcoming changes in Lua 5.4

[Mark Hamburg <mhamburg.ml@...>]

I don't know what the Lua 5.4 implementation is doing, but since it isn't clear whether arguments are varargs or regular args until one gets into the function itself, it certainly seems like if this were an issue it would be straightforward for the compiler to recognize when the function just passes the varargs along without accessing them in any other way and take appropriate steps to optimize for this case. In other words, at the very least, it doesn't seem like this has to be a concern.

Mark

On Wed, Jan 10, 2018 at 2:30 PM, Soni "They/Them" L. <fakedme@gmail.com> wrote:

On 2018-01-09 12:48 AM, Xavier Wang wrote:

云风 Cloud Wu <cloudwu@gmail.com <mailto:cloudwu@gmail.com>>于2018年1月9日 周二上午9:55写道：

    Roberto Ierusalimschy <roberto@inf.puc-rio.br
    <mailto:roberto@inf.puc-rio.br>>于2018年1月8日周一 下午8:36写道：

        vararg functions in critical paths often. Several (most?)
        vararg functions
        have to create tables (or pay the price of 'select') anyway.


    Can this one avoid vararg create tables in lua 5.4 ?

    function  print_with_tag(tag)
      return function(...)
        return print(tag, ...)
      end
    end


No. It have _ARG tables create when each time the inner function called. ... will be compiled as a bytecode based unpack.
--
regards,
Xavier Wang.

I definitely have questions about the performance of this:

table.pack(some, things, or_a, function_call, here)

vs this:

(function(...) return _ARGS end)(same, as, above)

Since the latter creates a table in bytecode.

I also wonder about the performance of this: https://github.com/SoniEx2/Stuff/tree/master/lua/Forth

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.