@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.
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.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
