[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua 5.1 has a serious issue
- From: D Burgess <dburgess@...>
- Date: Fri, 13 Jan 2006 10:32:54 +1100
Oh and Mike brings back to my memory the desirous
t[] =
append syntax.
DB
On 1/13/06, Mike Pall <mikelu-0601@mike.de> wrote:
> Hi,
>
> Daniel Silverstone wrote:
> > [...] Lua 5.1's new # operator.
> > Specifically it is that it does not invoke the __len metamethod on
> > tables, only on userdata.
>
> Ah. News. Well, as of May 19th 2005:
> http://lua-users.org/lists/lua-l/2005-05/msg00281.html
>
> > It's fairly easy to replace the chunk in lvm.c for handling OP_LEN for
> > tables to be something like:
>
> It's also fairly slow. Measuring #t on a plain empty table in a
> tight loop minus the loop overhead is 2x slower (!). Not good.
>
> A proper fix is to make __len a fast tag method. Then the
> overhead is down to 2% (much less when the table has elements).
> Much better.
>
> I've had a 'nice to have, but probably too expensive' opinion
> before. But in the light of this benchmark, I'd say go for it.
>
> > And such would save a lot of hassle and prevent us from having another
> > second-class metamethod to go alongside __gc.
>
> This has a very different rationale and is an inappropriate
> comparison. Please google for (e.g.) Java finalizers or
> reachability states to understand the problem. I severly doubt
> there is an elegant generic solution.
>
> > Otherwise I can see
> > many distributions applying such a patch as a "bugfix" which
> > will make varying and effectively incompatible versions of Lua
> > occupy our distributions.
>
> Yes, they can do that. Just not call it Lua anymore.
>
> PS: The choice of the subject line and the general tone of your
> message is not helpful for your agenda. Developers are
> usually most impressed by proper research, good code and
> convincing benchmarks.
>
> Bye,
> Mike
>