[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: C binding strategy
- From: Roberto Ierusalimschy <roberto@...>
- Date: Tue, 14 Aug 2012 09:30:49 -0300
> [...] > 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