[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] A new implement of Luiz's lmapm module
- From: Xavier Wang <weasley.wx@...>
- Date: Tue, 24 Apr 2012 10:33:32 +0800
Thank you for you reply :-)
I think if you only have one lua_State (not thread), then the module
is okay, static variable are shared between threads, but not states.
maybe I can add these static variable into a userdata in lua_State,
the original binding (from yours) is using static variables, so ...
but if I do that, I need lua_rawgetp everytimes if I want to do
calculate, is that affects performance?
2012/4/23 Luiz Henrique de Figueiredo <firstname.lastname@example.org>:
> Nice to see lmapm attract some interest.
>> this is a new implement of Luiz's lmapm module:
>> - renamed some functions:
> If you change the API, then it's not a reimplementation of lmapm:
> it's a new binding to MAPM, which is fine.
>> - use static work temporary variables to store intermediate result.
> This is a laudable goal, but the way you have implemented it, with
> static C variables, your library only works for a single Lua state or
> thread. In general, Lua libraries should not have static C data that
> depends on the Lua state.
> In your case, you could allocate temporary variables in the registry,
> but I'm not sure it's worth the trouble.
> For a C library whose objects have to be created by the library it's
> hard to avoid creating garbage. Some C libraries allow the user to init
> objects using local variables and this makes it easier to avoid *some*
> of the garbage when evaluating complex expressions. For instance, my
> bindings to qd and interval support this.
> However, the main source of garbage is intermediate results and this
> cannot be controlled automatically unless you do something like
> a=<complicated expression>
> and allow the binding to keep a stack of objects that is reused at
> the end; only the last object is keep.
> I think we have discussed this scheme in the past here (or was it in IRC?).
> Anyway, in a garbage collected language like Lua, you should not be (too)
> concerned about garbage, unless you create lots of it. Moreover, the
> generational mode in Lua 5.2 can probably mitigate this problem.