<div dir="ltr">Thanks very much Bill and Kjetil. Sounds like there is a lot to learn here. The thing that is confusing me right now is why it hasn't been a problem so far in my timing tests of scheduling. Hopefully you don't mind another barrage of questions.<div><br></div><div>Some background, basically I have two kinds of work going on: timing critical (notes and control events playing) and general i/o that is not critical (user moving dials, updating sequences, what have you). Right now I'm trying to make sure there are good options for users to pick their tradeoffs. Bizarrely, i've not noticed any delays from the GC running. I'm wondering if this is because the delay/schedule code works by having the max scheduler trigger it and that the GC never runs between wake up time and completion of those functions (which are pretty light). I think for my purposes, sub 5ms jitter is something we can live with, though i don't seem to even be getting that so far, but nor have I pushed it. This is really "event" real time, not audio real time. I'm going to call the pass at the interpreter that is run from the scheduler the "event pass" for nomenclature's sake..</div><div><div><br></div><div>Questions:</div><div>1) So if it traces live objects, does that mean minimizing the object tree in an instance will cut down the time it takes to run the GC? and is there any advantage to certain kinds of objects? As in, does it speed up the GC pass if I'm using top level globals and simply calling set on them so that there is not much for the GC to trace? Or any other code level strategies to speed up the GC pass?</div></div><div><br></div><div>2) I could just turn off the GC for these event passes. But I'm not clear how I let it run again as Bill said it can't be manually triggered (I do think that would be super helpful if you get that itch though Bill! :-) ) Do I need to run some scheme code with the GC back on and it will just happen? I would be totally fine with allocating a big heap and deferring the pass while "deliberating leaking" for a while. I was under the impression nothing happens in S7 until C makes a call, but am I wrong there? Does the GC sometimes just do it's thing from a thread? </div><div><br></div><div>3) I have been confused about threading in S7. It seems to me that it works fine for me to access the same S7 interp from multiple threads, but am I just getting lucky? I cooked up the option to lock the s4m object into 1 thread because I thought that at some point I was going to get data structure corruption if I have two different max threads making calls into the same interpreter. But am I wrong there? If it's actually safe (or I can make it safe somehow) for the multiple threads to call into the GC, would it work for me turn off the GC for all events in the high thread (triggered by midi input, clocks, or scheduler callback) and then let it run from a call to the low thread? In max there is an option to make a low-priority callback too, so I could perhaps use that to get the GC to run when I want it, in the lower thread only, preserving the critical timing.</div><div><br></div><div>Thanks everyone!</div><div>iain</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 23, 2020 at 5:57 AM <<a href="mailto:bil@ccrma.stanford.edu">bil@ccrma.stanford.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I forgot to say that I tried using separate threads for<br>
the gc (it is a natural for this in that the most<br>
compute-time expensive part is just spinning through<br>
the heap -- it can easily be split into N threads).<br>
But I got no speed up overall from this -- there's<br>
a brief comment in s7.c about it ca line 7079.<br>
<br>
</blockquote></div>