RE: fast metamethods (was: lua hacking wondering)

["Virgil Smith" <Virgil@...>]

So why not kill two birds with one stone.
Disallow metamethods on "simple" tables entirely.  Add a new type to the
language for tables that can have metatables.  Tables with metatables (like
full userdata) represent user defined types.

The requested metamethods could then be added without risking performance
degradation to tables in general (which is quite possibly a huge performance
threat to Lua as a whole).

OK, here's "the second bird".  If this new "extended table"(or whatever)
type is given a C-API accessible void* then it can replace full userdata and
simultaneously solve the per-userdata Lua-side value problem with no
"weak-table issues" involved.

I personally only see one caveat, and that is the globals table /
environments.  The problem with them is that they are very frequently
accessed, but also setting metamethods for them is extremely useful.

Well OK a second caveat is that I disagree with the authors concerning Lua
allocating memory for userdata's and so they might prefer that the C-side
accessible void* be a bit more than that in order to enable garbage
collection of some allocated space.  However, that detail is (I think)
irrelevant to the suggestion.




-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Roberto
Ierusalimschy
Sent: Wednesday, June 23, 2004 6:41 AM
To: Lua list
Subject: Re: fast metamethods (was: lua hacking wondering)


> This patch allows an alternative and much more efficient way of
> defining these metamethods.

Have you measured the speed up in "real-like" code?


> By the way, the addition of the fastTM field in the Udata structure
> does not impose additional memory usage, since that structure had some
> wasted space available (due to alignment/union issues).

Are you sure? In my machine, the original structure had 16 bytes, the
new one has 20 (which would go to 24 with double alignment).

-- Roberto