coll and threads
Does anyone have experiences with using many colls in a patch ?
I have just optimized a patch by removing all unnessecary UI objects and therefore I replaced all the hidden umenus with colls. Some are referring to the same and others are independent.
After this change I have experienced some thread / stack problems that I never had before. The patch has been used for many performances and has performed flawlessly (knock under table !!!)
Is coll a "slow" object concerning fast data retrieval ?
/Thomas
I have just investigated the population of colls in my patch and realized that I have a couple that are being dynamically modified while writing video via jit.qt.record and recording audio to a buffer.
I use the the colls to contain the postition and scale data for my 8 GL videoplanes.
I used to have hidden umenus for this job and it did'nt cause main thread crash problems.
Could this be the coll problem ?
Is there a thread bug in coll ?
all the very best,
thomas
> Is coll a "slow" object concerning fast data retrieval ?
I would say yes, but i don't know your patch.
In the case that you are using coll for numerical values, there are really faster ways : See few efficiency tests on coll in my "Efficiency-test-on-arrays.pat", attached to the first message in this topic : https://cycling74.com/forums/java-200-times-faster-almost-as-easy-to-use-so-why-javascript
I have just realized that it isn´t the colls that were the main problem.
I replaced them with umenus which I have used before (without problems) - and I still got a heavy crash in the main thread as the report says.
During my optimization of the whole patch I have somehow messed up the order of operations. Probably deleting some trigger objects or changed the order of messages !
I was actually sending the following messages at the same time:
"clear and resize 8 buffer objects",
"dispose 8 QT videos",
"erase a folder",
"create a new folder"
"16 GL messages"
Isn't this a good reason for the crash ?
I have a feeling that especially the last line of Open GL messages was the main crash course since I did'nt get a crash isolating them from the message order and sending them manually .
But now I have created a better row of operations using trigger objects, message dumps,delays and deferlow messages and it seems to work (several knocks on wood !!).
BTW - I can really recommend this brilliant article by Arne Eigenfeldt about structuring a patch.
@pizza olives: It would'nt make sense if I posted the patch since it is huge and you would have to spend a lot of time trying to navigate in it. But I will definetely share with this very generous forum when it is more readable.
@Alexandre: Thanks for your effiency test patch and info about the coll speed.
/thomas
I am sure you are right !!!
BTW - I found a brilliant article on the subject by Joshua Kit Clayton here:
In the article he mentions a patch that was included in Max 4 called Performance Options. I can't find it in the Max 5 folders. Is it still included or does it have another name ?
The Performance Options patch has been integrated into the Preferences under the Scheduler tab.