Forum

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:

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.