[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Heap usage and variable argument C functions
- From: "Cory Bloyd" <cory.bloyd@...>
- Date: Mon, 20 Dec 2004 21:55:58 -0600
This is my first message to the list, so I'll open with some due praise:
We are just starting to use Lua and it has been wonderful so far. We
currently have the runtime executing on five very different hardware
platforms each with very different compilers without generating a single
compiler warning. So far we have not needed to modify a single line of
the distributed code to accomplish our goals. Lua is truly a great work
of engineering!
On to the questions:
Quoting http://lua-users.org/wiki/OptimisingGarbageCollection
"function(foo, ...) end
Vararg functions create a table for the ellipsis (stored in 'arg')
each time the function is called."
I am assuming this does not apply to C functions called from Lua. C
functions do not inform the interpreter as to how many arguments they
expect so they technically always work in vararg mode. It is OK though
because they can interpret the parameter stack directly without needing
a temporary table. Am I correct?
I ask because we have a C function that will be called very frequently
from Lua and will need to accept a varying number of arguments. We are
yet another game development house adopting Lua. Therefore the time
spent in the garbage collector is a very sensitive issue for us.
Summarizing my understanding... The following is a complete list of
actions that involve garbage collectable allocation in Lua:
*Loading chunks of bytecode
*Creating tables, functions, strings, threads or userdata
*Resizing tables
*Calling Lua functions with variable parameters
So if I wanted to ideally use Lua without ever running the garbage
collector I could avoid vararg Lua functions and do all of the rest of
the actions during the initialization phase but not in the main update
loop. The only thing that I can't avoid is the fact that tables are
always constructed incrementally. Therefore the collector could
possibly be triggered during a table construction because of the
fragmentation they induce. I realize that table constructors are
syntactic sugar, but it would be nice if the compiler could pre-size the
table. Is there anything else I should be aware of?
Many thanks!
Cory