[chuck-users] recycling program

[Brad Garton]

I think with careful coding (and this goes down into the ugen level)  
you should be able to design fairly leak-less code without GC.  I ran  
an RTcmix script -- about 10 scheduled notes/second -- for several  
days without seeing any significant memory hit.

brad
http://music.columbia.edu/~brad


On Mar 17, 2009, at 11:08 PM, Kassen wrote:

> Rob;
>
> 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,
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users