> 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