Beta34 lacks 10 FPS vs 33.7

tell me this is due XP support ;]
about 5-7 fps drop for sure on same patch

which patch?

hey. can you narrow it down a bit?
what is debug mode saying?
is the performance drop also measurable when the patch is hidden?

the patch is quite big… it heavily packed with compute gsfx and a texarray… just noted some heavy TTY spam… looking for the source

did you find it?

what would you have prefered in this very patch:

  • a red node
  • a silent failure
  • NAN
  • the log message
  • the success pin

not in general. just in this case. what is the desired behavior in this case?

division by zero external bpm plug uses UDP but weren’t on so i had 60 / bpm 0
i switched gpu on 780, so now it up to 40 FPS.
i can tell u i would hate to have silent error.
red nodes when some thing bugging in tty sounds prolly best, since atm only option to locate error is to delete subpatches one by one. And it’s better not to have errors
Maybe a node id in TTY so u can find it.

about the header of the thread gonna run few more test, so far 33.7 feels less jerky.
the problem before i switched gpu was patch running 30 frames for 5 seconds then it had a lag about 1 FPS for second then it goes 30 again for 5 seconds… Hate this up’s’n downs…

and please make it easier to find a node by it’s address

hey!

Sorry for the trouble. Please have a look at the latest alpha!! If you are happy with the latest solution to this we would soon release another beta that includes the fix!


RED NODE now is the default for a failable node.
That way you get a hint that you are dividing by zero.
Anyway if you are ok with the fallback behavior you can just disable the warning for the node in question. The node will stay gray and nothing will be reported.

That way you get notified and can handle corner cases per failable node as you see fit:

  • You may ignore the warning and use the success pin to handle the failing slices.
    ** One way would be to use a select node to filter out the failing slices
    ** or a Switch to output a default like NAN or 42.
  • or you just ignore the error and stick with the default behavior.

/, mod and some spectral nodes are failable.

The default behavior:
In any case failable nodes keep running if a slice fails:
A failing slice computation just doesn’t write to the output pin(s). The successful slice computations still update their output slices…

That way you may have old values in your output. Which in some cases is more desirable than NAN or 0.


Please report back if you find the time for it.