|
|
Premature optimization question Yes. This is premature optimization. I'll live. So rather than build out a bunch of patches into a composition, I'm thinking about building a few master JS patches, and operating them like classes who send messages to each other. The main reason is I'm building a server in Node.JS, and I figure sometimes I could move code into / out of Node for different reasons. The premature optimization question is: Are JavaScript patches in QC a lot slower than the other patches? Are there any disadvantages to going JavaScript for logic? I might just use JS anyway, but I'd love to be informed about the speed hit / any other downsides people are aware of.
|
For logic operations in QC for me the JS patch is the goto. I was just trying to construct a marco using conventional patches that counted from 0 to n incrementing 1 each frame. I got something working with two math expression patches and then made a macro of it and it stopped. Went to the counter patch but it requires a false/true cycle on it's inputs to increment okay that's losing every other frame but will do. So I try to make a flip-flip (NAND gate feeding on itself) to feed the increase count input — more problems and half working patches. Arh!
So much easier for that sort of thing in JS, and obviously you can code it already. Where it slows down is performing lots of operations on 100+ item structures. If you place JS inside the iterator patch and pre-parse (destructure) the inputs you get faster results in SL (slower in Leopard) than iterating with a loop in JS patch. For that everybody who has crossed to Plugins he has told of massive speed gains.
Benchmark. Compare A/B for certainty and to find the cross-over point of labour:fps ratio. There's certainly many ways to accomplish things in QC which keeps it fun!