Re: The removal of function environments: An opportunity for optimization?

[Roberto Ierusalimschy <roberto@...>]

> I'm thinking about a single-entry cache in the funcproto
> pointing to its last created closure (for the GC a weak ref).
> When creating a new closure, one checks first if there's a
> cached one and if it has the same upvalues.  If that's the
> case, it could be reused, if not, a new closure is created.
> 
> What I'm not sure about is, whether these checks are cheap
> enough.  Closure creation stays at O(nupvalues) but the O
> gets bigger.

Only for cache misses. And most functions have few upvalues.


> And the GC has a little bit more work to do.

The GC could simply clear the cache when traversing the prototype
(and keep a barrier on the cache field).


> On the other hand, with the new environment I think a lot of
> functions will a have an upvalue for _ENV.

Yes, but with the cache this is not a problem, as frequently they
would share the same _ENV.

The bigest problem with this idea seems to be the "identification" of
different functions into one. This seems rare, but may cause quite hard
bugs. (Imagine the emulation of the old setfenv, using 'upvaluejoin',
over such clones...)

-- Roberto