 |
lua-l archive |
|
|
||
|
On Sep 5, 2013 3:41 PM, "Tim Hill" <drtimhill@gmail.com> wrote:
>
>
> On Sep 5, 2013, at 11:43 AM, Tom N Harris <telliamed@whoopdedo.org> wrote:
>
> > On Wednesday, September 04, 2013 08:42:48 PM Coda Highland wrote:
> >> Performance, mostly. That's a table lookup worth of overhead for every
> >> function that needs to fetch it. A C function accessing a field in the
> >> lua_State is substantially faster.
> >
> > So it's just the classic speed-vs-space tradeoff. Either waste time doing a
> > table lookup for the people who need it, or waste a pointer-sized field in
> > lua_State for the people who don't need it.
> >
> > LUAI_EXTRASPACE is kind of a nice compromise since the it costs nothing if you
> > don't use it. At the cost of having to recompile. But that may be necessary
> > anyway in uses where the registry isn't an option. For example, to store a
> > per-state mutex.
> >
> > --
> > tom <telliamed@whoopdedo.org>
> >
>
> Hmmm … i'd say the cost of ONE void* pointer in a Lua_State was pretty insubstantial, even if you spin up a LOT of them. it may even be free, since most heap managers round up allocated sizes to some power of 2 multiple, so the actual size of the allocated Lua_State may not change.
1. The minimal heap allocation is a multiple of page size in modern systems, not an arbitrary power of two.
2. The only relevant size constraint isn't heap bound. If you are eg. copying states, the possibly unused user pointer is going to touch a register.
>
> --Tim
>
>
>