UI Performance Issues

Hi, I’m workig on a gamma project with a decent complexity and I noticed that the performance of the UI is getting slower and slower. Every node that is created takes a long time to pop into existance and every IO box creation triggers an ever longer recompile (I guess that’s what the yellow progess bar in the top left corner represents). This is reaching a point where normal patching feels very unresponsive.

I tried to simulate this in a fresh patch, which I attached. I simply created an unreasonable amount of UI Elements, which should represent my complex patch. Of course it is understandable, that the UI would get slower, when drawing a lot of elements. But when I navigate to another patch. “Some process” in my example. The patching there is also very sluggish, even if the framerate that is displayed in a skia renderer is at a solid 60fps. Try creating an LFO for example, it will take way longer, then when there are no other UI elements in the document.
Is this a known limitation, or can I somehow improve my patching behaviour to maintain a constant UI performance?

Clickbait image:

UI Performance.vl (357.2 KB)

3 Likes

Just tried with 2020.2.0-0050 and 2020.1.4-0181 on my Laptop (corei7-7600U running @ 3,2 GHz). In both versions with just running the patch vvvv processor utilisation is about 35%. When creating or deleting a node processor utilisation goes up to approx. 55% for ~ 8-10 seconds. And the UI indeed feels sluggish.

Ok, I’m going to label this a bug to give the topic a bit more urgency.

The thing is, that in more complex projects every tiny change of any IO box triggers a seconds long recompile (or whatever it is), that also impacts rendering framerate.
This means, I can’t really use the IDE UI to test things in realtime.

Also I had the case, that I changed some IO box and while this is still compiling, I change something else. Sometimes the latter change doesn’t take effect and I have to redo it.

And one more issue: A lot of times, when I open let’s say a process, the nodes don’t show any timings and the tooltips are not displayed, even though the patch is clearly evaluated and called from outside.
I have to create an IO box or a node to trigger a compile, only then the tooltips etc are alive.

bump.

Sorry for not reacting earlier. Well yes, changing only values shouldn’t trigger the compiler. We do have ideas to accomplish this but didn’t have the time yet to try them out.
And yes, the tooltip should tell you when tracing isn’t available for a patch. With tracing I mean that the code which was emitted for a patch has a second code path where all values get traced. Those code paths are usually rather large and increase the compile time a lot. They also induce a little performance hit, as for each patch entered the system has to check whether it should run it with tracing enabled or not. For those reasons we currently enable tracing for non-library patches only. The system considers a document without an entry point (Application patch) as a library. So maybe that heuristic is too simple and we can come up with a better one of where tracing should by default be included and where not. I’m up for suggestions here.

That a change to an IO box gets dismissed completely doesn’t sound nice. We’ll need to figure out how to get to the bottom of this. I guess reproducing it isn’t easy… :/

So yes, I do share your concerns - I’ll come back here when I know more of when we plan to tackle those issues.

1 Like

No problem, thanks for the update.

Some more thoughts:

The compliation behaviour is still concerning me a bit. Value changes not triggering is a good step but I also experience this bevaiour:
I use complex library like in my case Kairos. Then I just create a node of that library in a fresh new patch. At this point everything is still very smooth. If I create an lfo (which is my “benchmark”) the time until it pops into existance is negligible.
Then I dive into the libary opening a lot of definitions and patches. Now everything is super slow. Creating the lfo anywhere takes ages. Even after closing everything again, the compile time is way up.
It almost seems like a bug, as if when I navigate through patches too quickly, which triggers recompiles when the last one wasn’t done yet somehow breaks something. (Very unspecific, I know.)
This basically resembles my experience in my real project at the moment.

For the tracing: I would be totally happy if the tooltips would show it, as these patches usally really are behaving more like a library. Maybe a shortcut to trigger the tracing would be enough.

Hi.
I still have these issues and they seem to get worse.
In more complex projects every tiny change triggers a very long compile pause:

UI Slow

And whart is worse is that in that time UI interactions are lost.
Entered values, patched links and position of nodes jump back to their last state.
To say this is annoying would be an understatement. I often find myself in a position, where I want to let’s say connect the three inputs of a Vector join. And I have to wait after every klick for a couple of seconds, so I don’t loose connections all the time.

UI Glitches

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.

5 Likes

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 …

1 Like

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.

1 Like

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.

lame

1 Like

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.

1 Like