I have seen it on last creation, using 17 shaders and one camera. I have stop everything in 25.1 to rewrite all in 23 and gain really performances.
I have seen it also last saturday on a live patching, wich is attached here.
On the jig of saturday, i was using my whitecat and VVVV on same laptop ( asus i7 + Nvidia 460M ):
whitecat doing lights and sending artnet dmx signal to VVVV. WhiteCat is consumming ressources on graphic card, and maybe said to be a little bit hudge.
the live patched here is running fine with whitecat on same computer with 23, but not really good with 25.1:
Windows are taking time to refresh and shows up patch ( black renderer is shown despite the ptch). Node browser takes time to refresh clearly and is sometimes blocked or late to arrive after mouse call.
This weird pach is quite simple and doesnt contains really big things. Some spreads, but not hundred and nothing enormous.
Thats why i m saying: 23 is faster , and 25.1 still needs improvement.
I know that devvvvs have done a great job to improve 24 to 25. The results in term of performances is real. But there is still need for 25.1 and upper to be lightened somewhere.
Another thing I noted since 24 is that double click to create a node takes more time now. maybe because the new tags in the browser. maybe it’s not a deep performance issue, but it “feels” like its taken more resources, specially when live patching.
part of shaders but i think this is like there was forgotten inside main loop execution something that should n t be there. no polygon work, no cpu issue.
is there any way to count millis to get time execution without main loop ?
ok got it timing
i guess you can count yourself a vvvv pro, you can’t fool me ;)
the “slow” nodebrowser is some feature introduced since being c# programmed. (correct me if i’m wrong) i agree, its not as snappy as the old one. doesn’t bother me too much anymore.
all the examples you give have nothing to do with the execution of the patch itself but with user interaction in the patch. that’s something vvvv is not really made for in a live context. userinteraction without interuptions is done with the renderer window, keyboard commands or external controllers.
doing mouse interactions with the vvvv gui or IOBoxes is no perfomace test at all. since the gui and the graph run in the same thread you should not use IOBoxes as gui elements for live settings, there are just there to adjust ‘code’ parameters. so use gui elements in a renderer and then do the perfomance tests…
turning dynamic plugins on / off is quite interesting. not sure if this brings an actual speed bonus. devs ?
btw. since using ssd’s and windows 7 i hardly notice any delays, not even in the node browser. that brings me to the conclusion that all these delays (nodebrowser startup, helpfiles of dynamic plugins ) are due to harddisk operations. faster hd = faster vvvv. or less hd operations = faster vvvv ?
Surely devvvs may tell us wich procedure may be toggable in vvvv environnement. About ssd and hd is the a question of temp memory ( cpu related) somewhere that would explain your no delay report?
I also observed that live patching has become much slower in the current beta. Also, mouse-interacting with IO boxes is much slower, to the point of being unusable in a live situation. Yes I’m aware that I’m not supposed to do it, but until now it worked pretty well (a little stutter), but now even changing “code” parameters introduced major stuttering, so I wonder what changed?
I will try to find the time to test more (and reproducibly) vs. b23.