When I went to test 50beta35.5_x64 with some existing patches, they ran incredibly slower - 5fps down from 60fps. Turning on debug timing I was able to track it down to the S (Value) and R (Value) nodes each showing 1300-2000 timings in 35.5 vs. 6-15 in 35.2 and 34.2. This makes 35.5 unusable for me.
This is in patches that use a lot (30+) of S nodes, both regular and advanced. So this does not show in a small test patch with only a few nodes.
Also the regular R nodes no longer pop up a selection menu of defined names, that was very handy. But then it sucked when you would save a patch with an undefined R node and it would lose the name - isn’t there some way to make both work?
I had something recently that was solved by putting frame delays after the r nodes.
Does this work for you?
I’m not sure this is a fix more a demo that somthing is wrong, almost like a loop without a frame delay has happened…
After going through my patch i no longer need the delays…
sorry to hear that. i tried to reproduce but am unable. none of what you both describes makes any sense to me. is any of these behaviors reproducable? attached a file that doesn’t surface the bugs at my machine, still it would be interesting if it behaves differently on your machine. all the nodes show 0 or 1 in debug mode on my new machine. what do they show at your machine? thanks for the help and sorry for the troule…
While not exactly the same behavior, I think this is probably related. I just added a new R node to your patch and did not select a source name (which does show a menu, my bad guess I had clicked on Value Advanced) then each of your S node’s timing goes to around 50 on my system.
Now I don’t think I’ve got any undefined R nodes in my patches (none show red under 34.2) but since they do not turn red under 35.5 I don’t know for sure, I’d have to check.
I just went to check catweasel’s FrameDelay fix and saw quite the opposite - as soon as you hook an IO box to an R node it goes to 50, but if you hook a FrameDelay to it it goes to 100!
yeah… (concerning bug hunt)
well it looks like the slowdown only happens when some receiver is not properly tuned. otherwise it’s fast as always.
i tried a few things to speed up the corner case, but it looks like this is the price we have to pay for the new feature of getting non-existing channel names remembered on receive nodes.
the channel list constantly tries to adjust to all existing senders, but the bad receiver forces its entry into the enumeration (hidden entry).
note to self: as long as we rely on index-based encodings of enumeration values in pins (not string-based) we just need to add the dummy entry to the list so that we can refer to its index in the pin…
there is whole other approach possible and in VL we try that different approach, however as this is much work and we only encounter the problem in corner cases where receivers are badly tuned we don’t make this a top priority.
Well,unfortunately this does not only happen when there is an R node with an undefined label; that was just something I tried and it showed a problem, but my real problem is happening in patches where there are no undefined R nodes. And trying to get that test case has been a beeee-yotch. But I think I found one.
This demonstrates some very weird behavior: apparently the R nodes need to be in another module, and there has to be more than one R node reading the same value - AND the R node Receive String enum has to be coming from an IO box! Deleting the IO box fixes it, as does deleting all but one of the subpatch instances. But if you ctrl-Z those nodes back, the timing does not go back up.
But WAIT there’s MORE! Notice that the first S node (the upper-right one, the first one in the .v4p file) is using 10-30x more time than the others. In one of my patches, something similar is happening with the corresponding R node. Note in the pic below how one R node (ScrW at the top) is using a ton of time, even though another R node referencing the same value is fine:
By reading all the .v4p files, I found the ScrW S node just happens to ALSO be the first one listed in the first module being loaded… Haven’t done the extreme code archeology to determine if that R mode is also the first one loaded or not though.
indeed. i could reproduce the performance drop over here and tackled the issue. please try the latest alpha. Please check your project and flag as resolved if everything behaves smoothly.
Notice that the first S node (the upper-right one, the first one in the .v4p file) is using 10-30x more time than the others.
This shouldn’t bother you. The update of the enumeration that lists all senders gets triggered by any of the senders and will only calculate once per frame. This is why one of the nodes takes more time than the other. I guess it’s the first one that needs to access the list somehow.
Well, “fixed” is a relative term. First off, when I run the sr10.v4p patch with today and yesterday’s alpha, I get this on two different machines:
If I go ahead and click through this, the timings have gotten much better, but the open patch timing is still twice what it is under 34.2 and 35.2, around 90-100 vs. 40-50. So better yes, but not back where it was.
Oh, and I tried saving that patch out under the alpha, but still get the same error on load. New unrelated bug, or does this have something to do with the S/R nodes?
Regarding the exception you get, alpha builds have the exception dialog by default enabled whereas beta builds do not and just log errors to the tty. So to make sure this is indeed a new phenomena do the following please:
Start beta 34.2, middle click in the empty 0.v4p and enable the exception dialog. After that open your patch. Does the exception pop up or not? If not do the same with beta 35.2 please. In case it doesn’t pop up there either we have indeed a new bugger.
