[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Lua's GC in interactive applications (games)... feedback appreciated!
- From: "Jonathan Branam" <sspeare@...>
- Date: Sun, 27 May 2001 19:55:52 -0700
I've been looking at Lua for a while now, and I think it is an excellent
embedded language. My interest is in using it as a scripting language for 3d
apps, mainly games. I need something that will work as a configuration or
data description language, and also something for scripting events and such.
Lua is excellent at both of these things. [Any information or tips from
others on this would be welcome as well!]
The only real problem that I have had is with Lua's Garbage Collection. It
seems to cause a pretty large hitch when it runs, and this isn't really
acceptable. It is also largely unpredictable as to when it will run
(although I understand that I can control this more).
I am trying to get some feedback on a number of work-arounds that I am
considering.
1) I could run the GC manually, and have it take a set amount of time. This
way I could run it every couple seconds or so, but not let it take too long.
I can use the built-in feedback to find out if I need to run it more often.
2) Avoid operations which cause orphans. The main problem here is that of
userdata. I added new types for Vectors, Rotations, Color, and other types
that are needed. But many operations on them don't alter the existing data,
but rather create new data. This is something that may be related to my use
of Lua, so any suggestions would be greatly appreciated. One thought I had,
was to create += type functions, this will stop some unneccesary orphans
(eg: vec = vec + 1 orphans the old value of vec. But vec:add(1) would not).
However, this will not fix more complicated expressions: vec = p0 + (t *
(p1-p0)).
3) Extend Lua so that my new types are "built-in" such as the Number type.
As far as I can tell, the Number type never impacts GC. It looks like most
of my types can fit into the Value union without adding extra space
overhead. This seems like an attractive option, but I am still not sure how
difficult this change will be. There are only 37 references to LUA_TNUMBER,
so it seems not too difficult. TObject is used 82 times. My concern is that
this won't really fix my problems, just make them much more infrequent
(which is still good).
4) Extend Lua's GC to be use more "active" ref counting. I'm not exactly
sure of the term for this, but basically what I mean is that whenever an
operation takes a reference to something, it increments the refcount, and
when it releases a reference, it decrements the refcount. And every time the
refcount is decremented, if it reaches zero, the object (or value) is
collected immediately. This also does not seem incredibly difficult, but I'm
sure it would take me a while and that I wouldn't catch all the errors for a
while. This seems like it would be generally useful to others as well, so I
might favor it if others are interested.
Currently, #4 (active ref counting) seems the most attractive to me, but the
time required to do it is questionable. I have been experimenting with Lua
for a while, but only recently started looking at the implementation. It is
impressively simple and compact, but I am worried about small changes
impacting the whole system (due to my inexperience).
Well, that's enough for now. Thanks for your time. I am very happy to
provide more information and examples if what I've said isn't clear (or to
determine if I'm off my rocker).
Thanks,
Jonathan