Re: "Random" delays in execution

["Jerome Vuarand" <jerome.vuarand@...>]

2008/10/31 Max van Rooij (van Rooij Electronics Design & Software
Engineering) <mvrooij@vanrooij-edse.nl>:
> I've already established that the GC is the culprit for the delays. I
> just need to run the GC at every coroutine.yield, and gone are my
> delays. I never experienced any other "bad" behaviour such as crashes,
> wrong answers or whatever. It was just the delays. The delays are caused
> by the GC.
>
> I only want to know, _why_ is the Lua memory required at run time for a
> thread growing? And it _appears_ to be growing proportional to the size
> of the cel variable. It doesn't matter what _type_ of data the cel
> variable holds. It also doesn't matter wheter or not this variable is
> actually used in the thread or in the program at all.
>
> My theory is, that with every thread create, some space is allocated for
> the thread (which is natural), but also some additional space for the
> "global" variables accasible for that thread...The space required for a
> thread should be constant, but it isn't. It's directly proportional to
> the size of the variable cel. This is weird behaviour.

There is no reason for such a behaviour. New threads only point to
their parent's global table. No deep copy of data ever happen
implicitly.

> Maybe a few hints on where to look in the Lua sources?

I have no knowledge of Lua internals, but what I know is that there
are many ways to 'implement' your problem from the bits of code that
you didn't supply. IMHO you should look there first (or allow us to
look there) before looking at Lua internals.

However since I've got time to waste, I modified the code you gave us
to make it compile.

- Funcs-n.lua is the init Lua code with numbers in cel
http://lua.pastey.net/100251-3i5k

- Funcs-u.lua is the init Lua code with userdata in cel
http://lua.pastey.net/100253-3s2p

- ApplThread.lua is the loop Lua code
http://lua.pastey.net/100257-1elm

- Lua.c is the main C program. It takes the init script name as first
parameter, and the number of coroutine created as second parameter.
http://lua.pastey.net/100256-4dom

And a few runs here:
> time Lua Funcs-n.lua 1024
0.059s
> time Lua Funcs-u.lua 1024
0.062s
> time Lua Funcs-n.lua 65536
2.368s
> time Lua Funcs-u.lua 65536
2.577s
> time Lua Funcs-n.lua 262144
9.466s
> time Lua Funcs-u.lua 262144
10.291s

There is a small increase when using userdata (5-9%). This is probably
due to the way the memory allocator works (ie. doubling already used
memory when more is necessary) and the fact that more memory is
allocated at startup when building the userdata table (and thus
doubling that is more costly).

On the other hand this is nothing compared to the 10 000% you
mentionned (20msec agains 1700-2500msec). So there must be something
different in your setup.