[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: C binding strategy
- From: Dimitris Papavasiliou <dpapavas@...>
- Date: Thu, 16 Aug 2012 11:48:51 +0300
If you're only interested in exposing array-like data, like points,
matrices, colors and the like you might want to take a look at my
luaarray module. It basically creates userdata objects that are, in
essence C arrays but have suitable metamethods so that they behave
just like Lua tables. So from the C side you can get a pointer to the
array but you can still access individual elements from Lua and use
them where you would use an array-like table and vice-versa. You can
find more information here:
http://www.nongnu.org/techne/lua/luaarray/
Dimitris
(PS: I also have a module that uses luaarray to provide 3D
transformations (rotations, scaling, etc.) but I haven't found the
time to properly release it yet. If anyone needs it I can try to
speed things up.)
On Tue, Aug 14, 2012 at 3:30 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> [...] > but what causes some
>> concern is memory usage. The userdata only contains a refcounted
>> pointer, irregardless of the size of the data pointed at by that
>> pointer. Simply put, the garbage collection fails to realise that
>> there is a difference between a "Point" and an "Image", and only
>> "sees" the memory burden of the pointer. It simply doesn't realise
>> that the memory footprint of a userdata may be bigger than the size
>> of the userdata itself, and when left to its own devices will
>> quickly cause memory to run out - even though the memory 'consumed'
>> by the lua state will remain low.
>
> When you create a new userdata, its size counts as "positive work" for
> the GC: the GC works harder to compensate that allocation. But that is
> only once. After the userdata is created, its size counts as "negative
> work" (in Lua 5.2) or does not count at all (in Lua 5.1) during each
> new GC cycle.
>
> ("Negative work" means that each time the collector traverses the
> userdata, it considers it did a lot of work; so, the larger the userdata
> the slower the collector.)
>
> So, I think all you need to compensate for this external memory is
> to call lua_gc(LUA_GCSTEP, data) with some appropriate 'data' when
> you create the userdata. ('data' should be more or less the size of
> the external object in Kbytes.)
>
> -- Roberto
>