I encountered the similar issue. Is there any update here? When I were watching the streamed video in Node20, the gamma of the speakers as well as other users are comparatively faster.
I guess my pc is not that weak… (intel i7-8700 @ 3.2GHz, 16GB memory, NVIDIA GeForce RTX 2070), and it happens no matter what I am using 2020.2.2 stable release or 2020.3.x preview
this depends on the size of the project. so in my experience it doesn’t happen in most of the helppatches, but as soon as your patch is a bit more complex you can see this behavior. maybe also depending on the general computer speed.
Thanks for reporting this issue since it sounds like a show stopper and discourage me to do the next project fully in gamma. Since every project becomes complex.
When we use VL in beta and dive into Core.Lib nodes, the software hangs/crashes on a regular basis. This might be the same cause as stated above.
Keep us updated on solving this compile problem, cheers.
edit: same behaviour in gamma, going into core lib nodes renders gamma unresponsive.
I think I’ve had an issue like this before. I think I ended up copying and pasting chunks of the patch into a new file. Some of the slowdowns are a mystery, but I believe they have something to do with opening a patch and that action alone triggering some sort of touch event so its priority is elevated for compilation changes. I’ve found that if you haven’t changed anything in the patch, reload it and close it (middle-click the tab), and on some occasions it prevents the recompilations.
Still, I’ve been enjoying Gamma lately. Even though the tracing itself slows down, the patching has felt pretty snappy, with little lag when dragging objects an so on.
The UI itself does seem to gobble up processing resources, as I notice when I go from a busy patch like the application to the definition area. CPU usage drops, and exported applications are happy.
one more observation: maybe it has to do with patches been saved with an older version.
for me, the issue comes and goes away without any reproducible pattern… i had it in my patch some days ago, and today it’s totally gone…
@Elias
The editor is a Skia Renderer, correct?
Could the performance issues also be related to the GPU resource cache limit?
Tested with multiple renderers and the limit seems to be per renderer not system-wide / per app.
Is there a way to access the GRContext of the editor?
Ok doesn’t seem to make any difference - at least with the testpatch:
maybe someone could try with an affected “real world” patch.
Yes it renders with Skia - but I don’t think the issues reported here are drawing related.
We’re currently sorting out the next steps now that Node20 is behind us. The issues raised in this thread will be reviewed as a part of that process. I think some of them are bugs and can be fixed while for others identifying performance bottlenecks in the compiler / hotswap might improve things but to get rid of them completely we might need to discuss/investigate some other options - like for example interpreting part of the graph and only compiling the leaves.
Thank you for reviewing this issue in your next step. I wish that it could be labeled as a task with a high priority. I wish so, because it is somehow painful to work on vl gamma now. I miss the day when vvvv programming was such a pleasure experience, but I don’t want to go back to beta …
I think what is most problematic, is that even changing IO Box values triggers a recompile.
Or even just moving any element in the patch.
This makes it very frustrating to change a system in real time with the vvvv UI - like in a more complex real world application.
On visualprogramming.net it says:
"vvvv has one mode: Runtime. Modify your program while it is running, compilation happens in the background.
With its state hot-reload technology, vvvv saves you precious time: There is no need to restart your program to see the effects of changes you make."
And I really think this is one of the best features, but with the current behaviour it feels like driving with the handbrake on.
Never mind the messy patch…
This often is my “patching” experience.
Halting the patch with F8 only helps a tiny bit. Mostly same laggy behaviour.
Same here … I know I wanted to setup a call with devvvvs to showcase this (you guys probably remember) but weren’t able to recreate it to this degree an hour prior to the call (what are the odds).
But overall it’s often similar to this, I don’t know what triggers it. After restarting Gamma it’s ok-ish at first …
Edit: While I could clearly blame some things on UI performance, the more likely culprit seems to be part of how the recompilation/Hotswapping is done. The really bad ones, like shown in your recording, happen when the little bar in the top left will basically not ever rest.
If it takes long once, it will also never go back to being fast in these cases.
Going back to the patch in the first post, I did a little recording of something that didn’t feel right at all, which might also explain the hard nature of re-creating and showcasing some behaviours, as they are kind of erratic.
Still, this is just one of the many problems we face I think, so we’re talking about many things at once in our project I guess.
@readme Thanks! Might I ask that you upload that UIPerformance.vl patch as well? Switching/closing patches and performance drops/comes back up is hopefully something easy to fix.
@mburk This looks really terrible. How often would you say that patch you’re showing is in use? If you look at it with the project explorer and traverse the UsedBy branches? Does it somehow make sense that it takes a long time because that patch ends up in 1000 places or does it not make any sense? It looks to me as if any change in that patch invalidates your whole project. Just wondering whether that’s correct or whether there’s an obvious bug.
But apart from that, it is still the goal to find a solution which also works in deep patch hierarchies. There’s one promising approach but it didn’t leave the sketch board yet - with 2021.3 soon out the door there should be time to look at it more closely.
It’s attached to Michael’s very first post right below the screenshot
In the project in question class processes are spawned all over the place that ultimately contain patches like the one shown in Michael’s GIF. We were already hoping that we could eventually show you guys the patches so you have an idea of the kind of real world examples people do and you can come up with ideas of what needs to be improved to make the patching experience better.
Ideally you might even be able to provide some improvements which make it less of a pain to work with right now until you had the time to tackle it on a wider scale?
@Elias Thanks for looking into this!
While it is true, that this patch is used a couple of dozen times, these problems are showing throughout the project.
I’m sure have a much deeper insight into why things are behaving the way they are, but here are a couple of other observations and thoughts:
It seems after a fresh restart of the patch (So really closing gamma and restarting, F8 + F5 doesn’t do anything here) things are not too slow. Once I start navigating down the patch hierarchy things get continually worse. It seems like as soon as a document or patch is compiled, it will get compiled again once I change anything in any patch. Not sure if that’s actually what happens, but it matches the perceived behaviour. If I for example make the mistake to open a node of the core lib, so navigate to the definition, things are pretty much over and I cannot really use the patch at all anymore because every interaction takes forever.
Another thought: Shouldn’t the whole tree totally ignore any change, that does not affect the tree itself? So for example, when I change something in a class - as long as the input/output signature doesn’t change the system should not reconsider everything else and trigger a huge recompile? Same for positions of nodes or values of IO boxes. As it is, vvvv totally looses some of it’s core features: I just can’t change IO box values in real time to try things out.
As quick fix, I would even appreciate a mode, that does not hotswap / recompile at all. So a more rigoros Stop (F8). Right now patching is so far off from any real time idea, that I might aswell completely separate the patching / developing from running the application.
This is also inside a class that’s used in a lot of places … but as I don’t really change the class at all, there should be no invalidation happening at all by merely moving a node around.
You can see how the Editor lags behind by checking when I press the mouse button to drag it. If I do it right after releasing it, the Editor won’t react fast enough to it and it takes a while until it gets responsive.
Even though the bar is not visible in the GIF, the compilation bar in the top left corner remains inactive in this example.
Some good news: That the IO boxes kept being active even after switching to a new tab will be fixed in upcoming builds. So the weirdness as seen in your video @readme should be gone.
@mburk Your idea is correct, if the signature of a patch doesn’t change, all dependent patches shouldn’t be invalidated. For that to work we’ll need to introduce an indirection in the target code so we can switch to the new patch without having to swap the object graph. That’s also what I meant in my previous post with promising approach.
In upcoming builds, we’ll also have a new behavior regarding the scheduling of certain tasks in the incremental compilation process. When patching along, there was a certain chance of interrupting the incremental compilation system in such a way that it basically had to retry over and over again. But the user actions would make it hard for the system to progress. With the new approach, the system should stabilize itself faster, even when the user doesn’t stop patching or navigating along.
Hi. Any updates on this? I’m sorry to keep bringing this up again, put the patching is just pain at this point, and I’m totally loosing it.
Just have a look at this - Nodes disappearing, values jumping etc: 
I basically have to wait for about 5 seconds after every click, to patch.
@mburk The plan is to give you a preview build which should address those issues. Because there were a lot of internal changes, we’d like to test the build in a little group first before merging the changes back into the 2021.4 branch.
