April 2 of this year. I found another record of me demonstrating the program the next week April 9 and it seemed to work at speed. Also I am pretty sure I have played with it recently in the past few weeks and it worked OK. I have tried to blame the internet and my computer heating up and slowing down but no culprit so far. Also it hasn't worked for at least several days now which would indicate that it is not a temporary circumstance. Also ringC always works and ringD doesn't indicating something about the code.
yes, thanks, I've also looked into this, and - as I've already suspected - my recent change to evaluation of generic "when" hats in v10.2 is responsible for this noticeable slow down in your project. The problem is, that the "slow down" in turn speeds up other features, and lets me lift the restrictions on what you can put into the "when" hat's predicate slot without getting a timeout error. Also, the new - slower - evaluation is actually much safer and keeps the system from locking up altogether. Hmm... let me think about how I can address this in the next minor release, so we can have our cake and eat it, too.
There are not many generic "when" and "broadcast and wait" blocks in "Gate?" sprites.
Just forever loops.
Jens,
It seems that "when" in companion with the "broadcast..." steals some frames 
MRE for this problem.
Test
Simple "when"
The slowdown is barely noticeable
Thanks, Dariusz. I'm happy to report that I've found the bottleneck: In the new evaluation scheme I'm starting a regular Snap process to evaluate the "when" hat blocks, and it attempts to draw a highlight ("halo") around the script all the time, even when it's not technically triggering the script (because, duh, it's using the process to evaluate the predicate). And we don't even see that halo because most of the time the process terminates again before it gets to display it, so all this graphics computation clogs us the system. If I suppress computing the halo until it actually wants to get shown everything runs super fast again, even in the new "slow" evaluation system.
Gonna take me a little while to get all the edge cases right, but I'm glad I've been able to put a finger on this. Thanks, @dardoro, for your help, and thanks @karlfant for the wonderful project that lets us optimize this once again!
Wow! Many thanks on thanksgiving to Jens and Dardoro.
thank you! So, I think I've optimized the thread manager, and for me your project runs pretty fast again in my current dev version. Can you please try your other projects in that and let me know if they also perform well again?
HI guys
Thank you. My latest version is working just fine now.
youtu.be/9r6-JZn2Haw
Well. There is one browser window for Snap! in which the program runs well and from which I made the movie yesterday. But It runs really slow like before in all other Snap! browser windows. Even a non logon edit window on another machine. Does the one logon have some special early access to the fix which has not been committed yet?
Logon confusion. I logon to home. I go to edit and I am not logged on. I log on to the edit window and I try to save and I am not logged on to the cloud and there is no option to log onto the cloud. they are all the same logon. Am I doing something wrong or is this the way it is supposed to work. Am I allowed to have multiple logons or multiple windows or both? None of this is clear from the manual.
The logons are making more sense today. Maybe I just had too many windows and different logons yesterday and closing a bunch with an overnight wait cleared the stage.
OK. I think I finally have this figured out. I went back over the messages. I had forgotten that I had likely clicked on your link to the development version which was running in the working logon.
I am complete and happy now. Thanks again for helping out.
We'll probably release the optimized version within the next week to production.
Thank you.I will keep an eye open for it.