lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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

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.