[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Suggestion: non-taggable (raw?) tables
- From: Luiz Henrique de Figueiredo <lhf@...>
- Date: Thu, 25 Nov 1999 01:14:01 -0200 (EDT)
> >> But, do you have a *need* for more speed?
> Oops, didn't mean that to sound like a general attack on Lua's speed,
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.]
>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.