Re: Key lookup optimizations...

  • From: Lance Thornblad <lance.thornblad@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 1 Sep 2015 13:08:44 -0600

Oops, meant "memoization."

On Tue, Sep 1, 2015 at 1:07 PM, Lance Thornblad <lance.thornblad@xxxxxxxxx>
wrote:

First of all, thanks for the quick response!

I'm actually using the BlitzMax wrapper for LuaJIT. I am not using FFI,
but rather exposing the functions in BlitzMax. I'm not sure if that would
be considered using the C API (you mean lua_pushcfunction?), but I've seen
no slowdown and the machine I'm using is hardly a beast.

Good to know that it caches subs like that...

Yes, memorization might be what I need. The results should be the same,
meaning the object found by the key. I suppose that could be
circumstantial, though.

Lance


On Tue, Sep 1, 2015 at 12:47 PM, Coda Highland <chighland@xxxxxxxxx>
wrote:

On Tue, Sep 1, 2015 at 11:39 AM, Lance Thornblad
<lance.thornblad@xxxxxxxxx> wrote:
I'm using LuaJIT with my game engine, and am wondering how hash table
optimizations are done (?). Game objects are exposed as userdata and
the
member lookup is done using a hidden table with a C function as its
__index
metamethod, as is typically done.

Since my C function does its own hash lookup, it occurs to me that I am
probably losing the benefit of optimization. When LuaJIT interprets
"foo.bar," for example, how is the "bar" part handled on subsequent
uses? I
assume the hash lookup doesn't have to happen every time that code is
called.

Is there any way you know that I can call my C function once, but
replace it
with something faster for subsequent calls?

Hope that makes sense...
Lance

LuaJIT does something called "common subexpression elimination" and
the dot operator participates in that. If you have:

a.b.c.d()
a.b.c.e()

then internally LuaJIT will do something like

local f = a.b.c
f.d()
f.e()

So you shouldn't need to worry about that. And if you find that you do
need to worry about it, you can just cache the intermediates
explicitly like the second example.

For the case of optimizing calls across into C, I think you might be
asking for memoization, but that only works if the function will
always return the same value when given the same parameters. If it's
an accessor into stuff that might change, then there's no way around
it.

A question to be asked: Are you using the Lua C API for exposing
functions to scripts, or are you using FFI? The former is RIDICULOUSLY
slow; the latter is nearly as fast as if you had made the same call in
C.

/s/ Adam



Other related posts: