[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: luac limitations
- From: Mike Pall <mikelu-0706@...>
- Date: Fri, 15 Jun 2007 01:11:58 +0200
Hi,
Roberto Ierusalimschy wrote:
> > is there a limitation in luac?
> >
> > luac: constant table overflow
> >
> > (some 140.000 table entries)
>
> There is a limitation (both in luac and lua), but it
> should be almost twice this size (2^18)...
He's probably using key = "value" pairs (two constants per entry). :-)
[To clarify: it's a limit on the number of constants for the code of a
single function, which in turn limits the size of a single table
constructor. There's no limit (other than memory) for the number of
elements in a table. Gigabyte-sized tables get a bit unwieldy, though.]
Which reminds me ... using Lua for data description is quite flexible of
course. A table constructor takes arbitrary expressions for both keys
and values. But the overhead seems a bit high for some standard cases,
such as an entirely (or mostly) constant table. Translating data to
(very repetitive) code and back has its costs (memory and speed).
I don't know how relevant this is in practice, though? Maybe it's more
of a problem for embedded usage. But I guess load time can be annoying
on the desktop, too.
A simple improvement would be to add a new opcode which copies a range
from the constant segment (or an indirection of it) to the array or hash
part.
A bit more adventurous would be to return a constant table held in the
prototype. In case this table is written to, it's transparently morphed
into a regular table. Nice side-effect: the GC doesn't need to traverse
the constant table itself. A reference to the prototype is sufficient.
Bye,
Mike