UI Performance Issues

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?

1 Like

@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: pain

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.

1 Like

first: that’s great news!

Any chance this change also lands in the 2021.3 branch?
Just because we’re not sure we can switch to the newer one because of possible other side effects.

@sebl It will not end up in the 2021.3 branch. There’re just too many changes and new features which would break compatibility. However the special preview build we’ll hand out in a smaller group will be based on the latest 2021.3 so we don’t have to think about other changes as well.


Latest 2021.4 previews now contain the new compiler ideas as discussed further up in this thread. Definition and implementation are decoupled. Most of the modifications done to a patch will only affect its implementation while a few will also affect its definition (like adding a new pin or renaming an operation). Only then dependent patches will need to be looked at as well by the compiler.

Thanks to this strategy the overall workload of the front and back-end compilers decreased drastically while patching. Also the hotswap is much simpler - it no longer needs to traverse the runtime graph, instead it knows exactly what targets of what proxies need to be switched.

The only drawback so far is a loss in runtime performance due to the needed indirection in the emitted target code. Should this become an issue for you please report (our thinking was that this will become less of an issue once we allow to pre-compile VL libraries).

Note that those indirections will not be present in an exported application.