Re: avoiding copy - Luajit FFI

[Fabio Kaminski <fabiokaminski@...>]

im answeraring myself.. rsrs

i think my solution will be a bytebuffer that can be handled in lua
itself but with a ffi ctype
..

that ctype(pointer) would be feeded in the C space, and in the lua context ..
you would call functions to do this copy defered .. or lazy as possible..

thank all!

(but i guess this thread could be a food of thought.. about some concerns)

On Tue, Jun 7, 2011 at 12:58 PM, Fabio Kaminski <fabiokaminski@gmail.com> wrote:
> On Tue, Jun 7, 2011 at 12:53 PM, Justin Cormack
> <justin@specialbusservice.com> wrote:
>> On Tue, Jun 7, 2011 at 3:54 PM, Fabio Kaminski <fabiokaminski@gmail.com>
>> wrote:
>>>
>>> Hi Folks,
>>>
>>> Im trying to get less memory copy as possible with luajit FFI, and in
>>> the api to get your hands in a (void *) or (char *) pointer
>>> is copying it through "ffi.string()" wich in turns, will create a lua
>>> string..
>>>
>>> my first question: why cant ffi.string() reuse the given pointer.. vm
>>> design? avoid concurrency races  from the C side?
>>>
>>> the c api "lua_pushlstring()" works the same way?
>>>
>>> second:
>>>
>>> When you simply need to push a string or even a file buffer thats
>>> fine, but if whe are talking about things like byte buffers over a
>>> network
>>> those copy would make it loose a lot of performance in the long run..
>>> even creating a bytebuffer on the C side and passing only the
>>> requested byte string on the lua api side..
>>>
>>> Anyone has found a way (writing c logic or not) to avoid those copies?
>>>
>>
>> Only call ffi.string when you absolutely need to, the rest of the time you
>> can just pass around the raw buffers. You can just allocate them with
>> ffi.new.
>> Justin
>>
>>
>
> Yeah, thats the way to go.. create more C abstraction  (and black
> boxes from lua app perspective) and try to switch C/Lua VM the least
> as possible..
>
> no skinny C interface for now..
>