lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Sep 10, 2013 at 11:37:03PM +0900, Miles Bader wrote:
> Tim Hill <drtimhill@gmail.com> writes:
> > It's pretty late here, but looking at your code isn't it always trying
> > to get not-present values? If so, I'm not sure if this can be extended
> > to Lua behavior when it gets values that are present in the Registry?
> 
> Indeed, and for the "integer" case, it uses huge integers, not the
> smallish integers you'd normally use.
> 
> I've modified the example program (see attachment) to use a more
> realistic case of a small number of already-present entries , and added
> tests for string accesses (using both lua_rawget and lua_getfield) too.
> 
> Here's the results I get (which granted, are likely on a different CPU
> etc than William used):

I originally ran the test on a 3 year old MacBook. This morning I ran the
code--modified to truncate i--on a 1 year old Mac Mini and the lua_rawgeti
and lua_rawgetp values flip on the initial run (before array indices benefit
from anything), so that integers are faster than pointers.

lua_rawgeti * 16777216: 0.240755
lua_rawgetp * 16777216: 0.29467
lua_pushvalue * 16777216: 0.141793
lua_rawgeti * 16777216: 0.181394 <-- faster with small i and table fill
lua_rawgetp * 16777216: 0.295675
lua_pushvalue * 16777216: 0.141186
lua_rawgeti * 16777216: 0.180775
lua_rawgetp * 16777216: 0.292403
lua_pushvalue * 16777216: 0.1415

I dunno... this seems all so very inconsequential. Using lightuserdata seems
very simple and clean (unlike string keys), and still perfectly performant.
But, I guess suum cuique pulchrum est.