Re: __method metamethod

[Greg Fitzgerald <garious@...>]

> It sounds to me like this is the time to put one's money where one's
> mouth is and put together a patch so that it can be tested instead of
> merely speculated upon.

Without changing the VM, I did some performance testing using Lua 5.2.
 Using the attached script, you can try:

# __index creates closure
$ perf stat lua main.lua slow
2.24 seconds

# __method bypasses closure creation
$ perf stat lua main.lua fast
1.91 seconds

# bypass helper function
$ perf stat lua main.lua faster
1.12 seconds

# use colon syntax
$ perf stat lua main.lua uberfast
0.86 seconds

As expected, the __method metamethod was a measurable improvement over
using __index and creating closures.  But to my surprise, I had to
cheat quite a bit to get within 20% of the performance of using colon
syntax.  It looks to me like table lookups in Lua are significantly
more expensive than the same lookup using the C API.  Maybe the VM can
get away with a few less typechecks?

My conclusion is that now one really needs to put one's money where
one's mouth is and patch the VM.  I don't have much experience in the
VM code, so if somebody beats me to it, thanks in advance.

-Greg

On Fri, Jul 19, 2013 at 5:51 PM, Coda Highland <chighland@gmail.com> wrote:
> On Fri, Jul 19, 2013 at 5:31 PM, Greg Fitzgerald <garious@gmail.com> wrote:
>> On Fri, Jul 19, 2013 at 4:02 PM, Javier Guerra Giraldez
>> <javier@guerrag.com> wrote:
>>> local f = o:m
>>>
>>> as syntax sugar to:
>>>
>>> local f = function(...) return o.m(o, ...)  end
>>
>> That would be a good addition too.
>>
>>
>>> i think it's better than Greg's proposal because it doesn't magically
>>> changes the meaning of an existing operator (dot)
>>
>> That's not exactly fair.  It magically changes the dot operator in the
>> same way the __index metamethod magically changes the dot operator.
>> Both are tucked under the hood.  From the user's perspective, the same
>> code could have just as easily been written with no metamethods at
>> all:
>>
>> local funcs = {
>>     inc = function(self)
>>         self.a = self.a + 1
>>         return self
>>     end
>> }
>>
>> local function new(t)
>>    local o = t or {a = 0}
>>    for k,f in pairs(funcs) do
>>       o[k] = function(...) return f(o, ...) end
>>    end
>>    return o
>> end
>>
>> assert(new().inc().inc().inc().a == 3)
>>
>>
>> Using the __index metamethod is a handy way of exposing a Lua library
>> with the familiar syntax of JavaScript, Python, Java, etc.  Using this
>> proposed __method metamethod is a technique for getting that syntax
>> without the performance regression.
>>
>> -Greg
>>
>
> Overloading : to work when not coupled with a parameter list is the
> better solution. It's still important to be able to access the unbound
> version of the method, so you want x.y to still return the unbound
> version, and you don't want to overload the behavior of . any more
> than it already is. Meanwhile, : without a parameter list is currently
> a syntax error, so adding it would cause no incompatibilities and
> minimal overhead (there would still be a __method dispatch on a:b()
> where there wasn't one before, but that overhead can be brought down
> to just a single comparison by requiring that __method be defined on
> the metatable already when setmetatable is called).
>
> That said... I'm not convinced that it would be anything more than
> syntactic sugar. Adding "bound functions" that aren't closures to the
> language... well, I can see how it could be done with less overhead
> than defining a closure, but would it actually make a substantive
> difference, and could it be done CLEANLY?
>
> It sounds to me like this is the time to put one's money where one's
> mouth is and put together a patch so that it can be tested instead of
> merely speculated upon.
>
> /s/ Adam
>

Attachment: main.lua
Description: Binary data