Re: LuaJIT-friendly API and data structure design
- From: Mike Pall <mike-1502@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sat, 21 Feb 2015 22:14:46 +0100
Luke Gorrie wrote:
> How is the efficiency of this FFI boxing compared with Lua boxing? I am
> expecting it to be much better because assigning a new value to an FFI box
> is morally a MOV instruction and the GC will not be involved.
Well, the FFI store to the box is certainly better.
But then ... the hoistable overhead for FFI types is a bit higher
(type checks etc.). If the iteration count is low or the code is
branchy, the manual FFI boxing approach might be slower. You'll
have to test it.
> How about the relative efficiency of the two API styles, 'packet.length(p)'
> vs 'p:length()'?
It it ends up in an inner loop, the overhead for both can be
eliminated. But, if not ...
For the functional style, manual caching of the function in an
immutable upvalue is the fastest way, e.g.:
local plength = packet.length
And, yes, for this to work, you'll have to write your code in the
correct top-down declaration order. :-p
The method style is quite efficient for FFI data, because the
compiler can optimize out all lookups and checks for the method
invocation. This is on par with immutable upvalues, because FFI
ctype metatables are immutable. And you avoid the manual caching.
--Mike
Other related posts:
