Performance implications of large FFI constants
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Wed, 26 Sep 2012 03:52:41 +0000
In coding up various FFI interfaces, I often run across this pattern: #define
something1 constant1#define something2 constant2#define something3
constant3etc. Sometimes they're actually bracketed in enums on the C side,
although the interface doesn't necessarily require that. When I code it in Lua,
I could do it a couple of ways: static const int something1 = constant1;static
const int something2 = constant2;static const int something3 = constant3; or
enum { something1 = constant1, something2 = constant2, something3 =
constant3, -- etc}; or
local Constants = { something1 = constant1, something2 = constant2,
something3 = constant3, -- etc} return { FFI = Constants -- among other
things} Question: Which way is the 'best'. Of course that's a loaded question.
Here are my concerns.I want to be able to access the thing easilyI want the
access to be as fast as possibleI want to avoid collisions with constants that
might be defined elsewhere. I'm wanting to favor the last case because it
allows for the isolation, but incurs a lookup when accessed. But then, I think
all of them do? Or would the compiler turn some of these into something
faster, like the static one? The later case makes things a bit clunky in usage:
local dwFlags = bor(U32.FFI.MWMO_ALERTABLE,U32.FFI.MWMO_INPUTAVAILABLE)
That's a far cry from local dwFlags = bor(MWMO_ALERTABLE, MWMO_INPUTAVAILABLE)
It might just be a stylistic preference, but does anyone have any concrete
thoughts on which way might be best, or most palatable? -- William
===============================
- Shaping clay is easier than digging it out of the ground.
Other related posts:
