Re: Suggestion: non-taggable (raw?) tables

[Luiz Henrique de Figueiredo <lhf@...>]

> >> But, do you have a *need* for more speed?
>
>   Oops, didn't mean that to sound like a general attack on Lua's speed,
>sorry.

No offence taken. It didn't sound like that at all to me.
I'm sorry if I sounded defensive.

>   Without question Lua is fast enough *as is* for everything I initially
>expected it to do, and more.  In fact, partly due to its speed I've ended
>up doing a lot more "inside" Lua than I had originally intended

That's our experience here at TeCGraf too.

It's kind of a mental block that needs to be overcome:
 C is not really needed except to provide services to Lua; a very large
 part of the application can be written in Lua (it'll get done faster
 and it'll probably be more nicely coded!).

[I'd like to hear about other people's experience with this. Please post.]

>leading me
>to look for various techniques to optimize that code so that I can ask it
>to do EVEN MORE. (within the processor budget constraints that I'm under)

Just curious, what processor? I'm under the impression that you're using
Lua in a embedded processor.

>   One thing that is obvious, for example, is that accessing locals is
>faster than globals.

This is true. But I don't know how much faster.
Like GETTABLE, GETGLOBAL also costs about 2 C function calls.

>The trade-off is that locals don't make good storage
>locations for large "static" data due to the setup time at function entry. 
>So I was playing with various ways I might alias into a big global table
>that I have, and wondering if there were anything else that could be done
>to get it to perform speedwise more like locals.

It seems to me that upvalues would be useful here.
They're static and as cheap as locals.
Plus, if the upvalue is a table, then it's not static in the sense that its
fields can still be modified.

Also, keep in mind that access to a big table is not likely to be slower
than to a small table: table accesses are supposed to take constant time.

>   So, while wondering about the relative speed of get/set globals vs
>locals, I also wondered about get/set table and any overhead it might have.
> But, if the VM knowing in advance that the table could not possibly be
>tagged wouldn't yield much in performance, then it's not worth considering.

Like I said, you'd have to measure this in your application.

--lhf