Re: [ANN] A new implement of Luiz's lmapm module

[Xavier Wang <weasley.wx@...>]

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 <lhf@tecgraf.puc-rio.br>:
> 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
>
>        begin_evaluate()
>                a=<complicated expression>
>        end_evaluate()
>
> 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.
>