[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: userdata environment
- From: Mark Hamburg <mark@...>
- Date: Sat, 12 Sep 2009 11:30:30 -0700
The garbage collector may also expect that the environment is a table
rather than an arbitrary object. That would be the other place to
check when making changes.
Benchmarks are of course the "right" thing to do. The problem is
figuring out what to measure that will be meaningful in a general
context. if you need to create lots of userdata with an associated
string, for example, then the intermediate table represents more
memory, more steps on access, and more material for the GC to trace.
That's all bad. On the other hand, there may be other parts of the
system that benefit from the simplification of having environments
always be tables and if you only occasionally need the non-table case,
those cases might win out. So meaningful benchmarks need to know how
to hit both sides of the case and how to compare them. Sorry, I can't
offer any guidance there.
Personally, on Lightroom, I wished for the ability to store nil in the
userdata environment table. For proxies for Objective-C objects,
Lightroom uses the userdata environment to store links to other Lua
values. That works well, but it takes special work to make sure the
proxy stays alive even if the only references to the underlying value
are to the native Objective-C object. We only want to do that special
work when necessary and hence it would be convenient to have an easy
way to tell whether or not a proxy has a custom environment. As it is,
I forget whether I ended up assigning a special default environment
and testing for equality or whether I encoded some flags into the
proxy value. Neither solution was as attractive as simply storing nil
in the environment.