since beta24, vvvv starts up really slow. i tried the new release on a HP Touchsmart PC and it is even more a pain than on my SSD driven machine.
proposition:
I think its time for some feedback of whats going on or some loading bar. just something giving you a clue the software is not crashed.
second, the node browser is taking ‘ages’ after startup as well. isn’t there a way to cache things of whatever it’s doing the first time ?
same applies to program startup. any chance to improve speed ?
why i don’t like it ?
i always loved the ‘snapiness’ of vvvv. open the program like you take a sheet of paper and patch down your idea. that’s gone now…it starts up like photoshop. and its not just me, some of my beginner students asked me if the program is crashed on startup. that’s not a good feedback.
Yeah it has been getting slower, and on some machines it’s slower than others even beta 21 etc, which is weird.
I’d like to ask again if it’s possible for a renderer to start up black grey is nasty if your patched straight into beamers…
Either hide till initialized or black would be much nicer when opening patches, a loading progress would be good, esoecially big patches, it’s hard to know whether you missed a double click, I gave been known to start patches twice!
same here with the double click, wondering if it’s running or not…
to add to my initial post, the splashscreen should be the first thing being executed…
as i am avery fast patcher/clicker, beta24.1 really slows me down in patching.
also i don’t like those occassional crashes.
for serious things i am still on beta23.
guess vvvv come slower because of code editor and dynamic nodes, when creating some .cashe and so on
dynamic nodes are great but really need some solution.
probably need somekind of developing mode for vvvv (even if it opposite main vvvv concept - running mode only)
devvvvs are super smart and will find brilliant solution here)
sorry to chime in here, but i totally agree with all of you. like kalle i’m still on beta 23 for mission-critical stuff. On the other hand the code editor really opens a whole world of new possibilities (in rapid design and prototyping that is), so i’ll probably just wait one or two more releases for the new stuff to mature before i completely switch over.
on a sidenote: can we have the auto-compile button in the shader code editor back? puuhhhleeeaaaaase… ;)
Hi Dev, is there any news on that issue , or any way to speed up startup, currently my patches took in general around 1mn to load witch is quite long.
I did try many things to speedup startup without success, my patches use kinect2, dx11 and a couple of dynamic plugin, and are not very complex, just a few sub-patches and shader.
Will be really great to have a fast startup like 10 seconds…
suspecting that amount of total nodes vvvv has to scan on startup is proportinal to how much lag u have on start…
e.g. remove addonpack, native nodes and see if it speeds things up
at least for dx11-pack and kinect2 you should be able to create one such.
deleting helps, assets, girlpowers or modifying diff should not make any difference.
one other thing you should notice: whenever you start vvvv for the first time after a PC-reboot, it takes longest. second time around it should already be quicker because windows apparently does some caching. so consider that when doing tests. also check the difference between starting up:
Thanks Joreg, i’m not sure if i understand correctly, i don’t need to edit the patch ,just play it, so to speed up startup, should i use and empty nodelist?
Anyway found out the main problem was somehow coming from my patch, i was using dynamicbuffer with huge spreadcount, and they actually store the data into the xml. My patch was 200mb big… that’s why … After saving with empty spread now my patch is loading in less than 10sec…
Anyway thx for the help… and maybe this will help other people to sort out the same problem…
A lot of nodes have pins whose content is saved into the xml; at least, almost every string type node; even though, imho, this is due to the workflow used while patching, I find really tricky not to have a pin’s content saved in v4p, up to the point I gave up trying, and started cleaning the xml afterwards. In fact, even linking an empty IOBox, in a few cases, will not clear up a pin’s content after saving. This is probably bound to something that I would technically describe as “stuff ain’t flowing”.
In the very beginning of my patching it also screwed logic - which, in all evidence, was somehow already flawed.
@sanch vvvv is checking for every pack if there is a nodelist.xml. if so, it can quickly load that file, read its content and fill the nodelist. if you’re providing an empty nodelist.xml you’ll get an empty nodebrowser, which is not what you want. providing no nodelist.xml means vvvv has to parse all folders to look for nodes, which is slow.
regarding huge spreads saved in a nodes input pin, see:
