[chuck-users] recycling program
rdpoor at gmail.com
Wed Mar 18 01:53:44 EDT 2009
Kas (and ChucK community):
The code I'm writing really needs a "wait-on-event-or-timeout-
whichever-comes-first" function, and the obvious way to write this is
to spork a shred at each call. Since I will be using ChucK in live
performances, the fact that memory is exhausted after 20K calls to
woeotwcf is a concern to me. If shreds are allocated from a pool, then
profligate sporking isn't what's causing the system to run out of
memory, but without monitoring tools, I have no way to know.
The short statement is "I can't optimize what I can't see". It would
be nice to have visibility into where the storage is getting eaten
up. Or a GC.
On 17 Mar 2009, at 20:08, Kassen wrote:
> Are there tools or techniques for monitoring memory allocation in
> ChucK? I've been stress testing my code, and after about five hours
> ChucK vm stops with a malloc / mmap failure. It would be nice to
> figure out what's clogging memory. [In a previous life, I was an
> embedded systems programmer, so I'm happy to create reusable object
> pools and managing the objects myself, but I need to know what leaks
> and what doesn't.]
> From my experience (looking at task manager on Windows and Top on
> Linux) defining anything will allocate memory and this won't ever be
> freed. I'm not sure what the current state of garbage collection is
> but last time I checked I believe this even included the temporary
> variables in "for" loops. In case of doubt it's currently fairly
> safe to assume it'll leak though memory allocated for samples should
> be freed (I think).
> For some types of program you can simply make sure to never define
> anything inside of loops, going as far as to re-use the temporary
> variables in those "for" loops. I think that can lead to garbage-
> less code but I'm not sure about function calls.
> That's the bad news (I think everybody agrees this is quite bad).
> the good news is that it's being worked on and some GC is
> (supposedly) already in place.
> One of the most important techniques I use to deal with this is
> making sure anything "large" (classes, UGens) of which I need
> multiple copies will be stored in a array so I can re-use one copy
> once I'm done with it; basically I try to make sure it never becomes
> impossible to address. This creates some overhead in code and
> complexity but at least memory leakage will be contained to
> reasonable levels.
> Hope that clarifies,
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users