[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Userdata environment
- From: "Alex Davies" <alex.mania@...>
- Date: Mon, 31 Mar 2008 21:27:30 +0800
Simply to save memory. A pointer to a table takes some 4 bytes (x86), where
as a fully tagged value takes 12-16 bytes depending on alignment. When you
consider that many people use userdata just to store 8-16 bytes, that's
quite an optimization. Also by ensuring that the environment is never null,
a minor time/complexity saving can be made there. (as getenv always returns
The other way around your problem is of course to use a single weak keyed
table, and your userdata as keys. It'd save a fair amount of memory, but I'm
not sure which is better from a gc perspective.
----- Original Message -----
From: "Shmuel Zeigerman"
To: "Lua list"
Sent: Monday, March 31, 2008 10:07 PM
Subject: Userdata environment
Is there some reason behind enforcing userdata environment to be a table?
I'd like to associate some userdata B with already existing non-table
value A. To achieve that, I have to create a new table, put A in there,
and set that table as the environment for B. This new table seems totally
unnecessary and affects efficiency. (I'd like to be able to just set A as
the environment for B.)
A related issue: it seems that when a new userdata is created, its
environment is set to the C-function environment. The Manual doesn't say
anything about that. Is that an undocumented feature that is likely to
change? Or am I overlooking something?