Hi Mike, thanks for the reply What I'm doing is an installation which will run for about an hour. I get some control signals from other laptops and according to some logic set parameters to my audio algorithms / synthesis (so yes, I'm doing sound :-) ). This logic includes a loop and a triple (nested) loop, quite necessary. They are not repeated at sample rate, they will be probably repeated every 30 seconds approximately BUT they will be repeated for a whole hour, that's why I was worried. I will try to test it when I have an hour and see if I run out of memory. But maybe it's a better idea to implement the logic in SuperCollider and send the outcome to ChucK.

...

From Kas:

Still; in many cases I end up defining the variables outside of the loop (but inside of >>the class or function) and where we'd normally instantiate them I reset them to 0. >>I'm not religious about this as often it's not worth the trouble but for tight, continual >>loops in long term projects I do it and sometimes even go as far as recycling the variables I use for "for" loops

Hi all,

as i've read in the documentation or maybe in some email in this list, ChucK lacks garbage collector. If my understanding is correct this means that it does not automatically free the memory that any variable needs after getting out of its scope. So this probably mean that if I run a loop that declares a variables like

for( int i = 0; i < 100; i++; ) {     int var1; float var2[10];     // do things }

and have this code called many times inside an infinite loop and do other stuff in other shreds, after a while it's inevitable to run into

Thanks Kas, yes I use all these techniques, I think I will even try to define the variables outside the class/function and pass it by reference if I see that I have a problem so that memory is allocated only once. I think actually that this might solve the problem. (I hope that it's not only objects/arrays that you pass by reference in ChucK, I'll have to check the manual...) Dimitris --- Στις Παρ., 20/03/09, ο/η mike clemow έγραψε: Από: mike clemow Θέμα: Re: [chuck-users] variables and memory Προς: dbozelos@yahoo.gr, "ChucK Users Mailing List" Ημερομηνία: Παρασκευή, 20 Μάρτιος 2009, 22:51 Hi Dimitris, It's true that ChucK isn't great with garbage collection. I implemented your code so that it ran every sample: while ( true ) { for( 0 => int i; i < 100; i++ ) { int var1; float var2[10]; // do things 1::samp => now; } } Yes: this ate about a 1Gb of memory in a few minutes. HOWEVER, I've rarely found that I needed to do something this abusive to ChucK. To be fair, this code was designed to do nothing but eat memory... hopefully, you'll be asking ChucK to do something important (like make sound). Also, since you'll most likely be letting time pass to implement some sort of control rate for what you're doing (e.g. someduration => now;) this usually isn't happening every sample. And just because ChucK won't blink an eye at a control rate of every-sample doesn't mean that it's always a good idea. In theory, the above seems like a huge limitation. In practice, I find that there are other bugs and things that I generally have to fight long before I get annoyed about garbage collection. ;-) What exactly are planning on doing? Perhaps there's a way to do it without declaring so many variables. Cheers, Mike 2009/3/20 Bozelos Dimitris : problems.

Is this correct? Is there anything like c++'s delete to free memory?

Dimitris

________________________________ Χρησιμοποιείτε Yahoo! Βαρεθήκατε τα ενοχλητικά μηνύ ματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

Eduard, Kassen,

That's interesting but are you sure that memory will actually be freed in that case? I'm not so sure about that.

Kassen, he's right! It is freed. At least, with his addition, the code we posted stayed steady in the memory dept. Very low usage and never changed. Without that line, it eats up memory until it's all gone. while ( true ) { for( 0 => int i; i < 100; i++ ) { int var1; float var2[10]; // do things 1::samp => now; NULL @=> var2; // this frees memory. } } Well, that's very interesting... I have a lot of code that I want to go back over and see if it uses less memory if I judiciously set object references to NULL when I'm done with stuff. There's your destroy method, Dimitris! Όλα Καλά!! -Mike 2009/3/21 Kassen

Dimitris;

...

Thanks Kas, yes I use all these techniques, I think I will even try to define the variables outside the class/function and pass it by reference if I see that I have a problem so that memory is allocated only once. I think actually that this might solve the problem. (I hope that it's not only objects/arrays that you pass by reference in ChucK, I'll have to check the manual...)

I think most of our problems can be solved with this kind of technique, at least practically speaking.

Still; I do think there are techniques that would be very worthwhile that aren't being explored in ChucK right now because doing so would lead to memory issues. For example recursion; we can use recursion (it's even used in the examples) but we tend not to. For me part of the reason there is that I fear the amount of garbage. For practical things I can re-write most things linearly so it's no big deal but a recursive approach might be extremely interesting on a compositional level.

I suspect having GC will open the door to new techniques that would be impractical to explore right now.

Eduard;

That's interesting but are you sure that memory will actually be freed in that case? I'm not so sure about that.

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Kassen, I've often seen this type of thing... 0 => int i; for(0 => i; i < 10; i++ ) { // stuff } for(0 => i; i < 10; i++ ) { // more stuff } just keep reusing the same iterator integer, which I assumed you were talking about earlier. Also, this is going to be a lot more important for object references and large arrays, etc. but it's neat trick that I didn't know about before _mike 2009/3/21 Kassen :

Mike;

...

 Όλα Καλά!!

I'll assume that translates to "w00t"? :¬D

Three cheers for Eduard!

This won't work on floats and ints though ( for strings it's fine). Arrays of length 1, on the other hand, can be dealt with in this way if we really urgently must clean up everything.

Sadly that will make for loops look like this;

for (int n[1]; n[0] <= 5; n[0]++)     {     <<>>;     if( n[0] == 5) {null @=> n; break;}     }

That's not going to win any beauty awards. Ahum.

Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

By the way, ChucK's memory model is similar to Java's in that primitive types are allocated on the stack, while anything object-y is on the heap. In other words, ints, floats, durs, times, complex's, polars, and empty references won't have any memory cost after their enclosing scope ends. For example, I can run this loop forever without seeing any particular increase in memory usage: while(true) { 0 => int i; // type can be int, float, dur, time, complex, polar, or empty reference 1::samp => now; } So, with regards to setting things to null to free their memory, ints, floats, etc. can't be set to null, but their memory does not normally need freeing. spencer On Mar 21, 2009, at 2:49 PM, mike clemow wrote:

Kassen,

I've often seen this type of thing...

0 => int i;

for(0 => i; i < 10; i++ ) { // stuff }

for(0 => i; i < 10; i++ ) { // more stuff }

just keep reusing the same iterator integer, which I assumed you were talking about earlier.

Also, this is going to be a lot more important for object references and large arrays, etc. but it's neat trick that I didn't know about before

_mike

2009/3/21 Kassen :

...

Mike;

...

Όλα Καλά!!

I'll assume that translates to "w00t"? :¬D

Three cheers for Eduard!

This won't work on floats and ints though ( for strings it's fine). Arrays of length 1, on the other hand, can be dealt with in this way if we really urgently must clean up everything.

Sadly that will make for loops look like this;

for (int n[1]; n[0] <= 5; n[0]++) { <<>>; if( n[0] == 5) {null @=> n; break;} }

That's not going to win any beauty awards. Ahum.

Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Spencer wrote; So, with regards to setting things to null to free their memory, ints,

floats, etc. can't be set to null, but their memory does not normally need freeing.

I had another look into this and I'm cleaning up some of the tricks I pulled hoping to save on memory leakage with this knowledge. It does strike me that function calls leak rather a lot of memory, even for functions in which nothing gets defined beyond their parameters (which are primitives, in this case). Is there any way to avoid this? Maybe I should leave it be and wait for the next version to see if the proper GC addresses the issue? Yours, Kas.