[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: void* in Lua_State for Application?
- From: Tim Hill <drtimhill@...>
- Date: Fri, 6 Sep 2013 12:37:46 -0700
On Sep 6, 2013, at 11:36 AM, Patrick Donnelly <batrick@batbytes.com> 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.
--Tim