lua-users home
lua-l archive

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

On Sep 6, 2013, at 11:36 AM, Patrick Donnelly <> wrote:

> Hi Tim,
>> Yes I did. The C API is a mix of heavy-ish functions that do a  chunk of work, and some very light operation that just get/set values from a structure; it's these light ones that concerned me.
>> On an x86 system compiled for 64-bit code (cannot recall the CPU, but was recent pedigree), we saw about a 20-30% performance drop when using the registry
> Use the registry how? Using a light userdata index? Using an integer
> lookup in the array part?
> Have you tried using C function upvalues?
> A 20-30% performance drop in the application? Seems like a design
> problem to me if you're calling the C function that frequently when it
> won't logically do anything most of the time (as you've described
> elsewhere).

No, the 20-30% pert difference was running a synthetic test of using the registry to recover the state pointer versus using a custom allocator hack, with a minimal Lua -> C function call/return. The registry was accessed using lua_rawgeti() or (i think), lua_rawgetp(), which, if I recall, was slightly slower. Obviously if we had used the registry we would have needed to use lua_rawgetp() since the requirement was to convert Lua_State* to Private_State* as quickly as possible.

Agreed about the shape of the API and the dubiousness of lots of tiny calls, but sadly this is a legacy APi that we need to continue to support. If I had my wish I'd recode the whole thing to be far cleaner.