I created a game using the visual scripting and the performance is terrible. When can we expect an update that will bring performance improvements? What visual scripting version number is expected to receive the performance improvements?
1 Like
hi,
We’re working on a new backend that should help with the performance. No ETA for the moment, we want to be really sure it’s ready. however:
- the performance of VS, at the moment, is highly dependent on how you make your graphs
- VS, by nature, will always incomb a performance cost
can you show your graphs ? maybe there’s a few easy wins in terms of perfs.
What will this new backend do differently exactly?
Current runtime is reflection based. Reflection is a slow process by default. The current variables system also produces a lot of garbage since it holds most variables in <string, object> dictionaries which causes type boxing. You can get a lot of performance by simply forgoing the variables system and holding all variables in C# scripts and offloading the performance intensive logic to C# scripts.
The new runtime will be a specific kind of C# gen (per-node C# generation). It won’t output regular C# scripts, however. Not sure if anything is being done with the variables system.
Thanks for the info. Manually moving vars to scripts isn’t difficult, but annoying if you’ve to crack open an editor just to do so.
no boxing, no reflection, split the authoring and runtime data and a few more things
1 Like
Thanks for clarifying. That’s awesome, and is definitely reassuring in terms of using it now, knowing that it definitely will get even better.
And that’s only the start, we’ve barely optimized the new runtime and see on average a 8x improvement (to be validated in real world conditions, but I think it should be similar)
Oh wow, that’s quite an improvement. Exciting stuff!
Is that mean we don’t have to manually add a new namespace and let it scan anytime we add a new one?
Even in a mid-sized project, this is getting very tedious very quick.
Hello,
I have terrible Perf on UVS too, i have seen you wrote : “You can get a lot of performance by simply forgoing the variables system and holding all variables in C# scripts and offloading the performance intensive logic to C# scripts”
How do you do it please?
By writing code in C#, then exposing it to UnityVS. There are two methods of doing that - reflection or custom coded nodes. Perf wise they’re similar. UnityVS can get and set any public C# variables as well as trigger any public C# method from graph. To expose a C# script’s variables and/or methods you go to Project Settings/Visual Scripting and add your C# script as a new Type. Then regenerate nodes. Now any public C# script contents will come up in regular UnityVS search.
Random example code for C# variables:
using System.Collections.Generic;
using Unity.VisualScripting;
using UnityEngine;
//This attribute automatically adds the script to Node library. Let's you skip the GUI step of adding the type manually but you still have to rebuild nodes in Project Settings.
[IncludeInSettings(true)]
public class TestScript : MonoBehaviour
{
//variables have to be public so that Visual Scripting can access them
public GameObject testObject;
public string testString;
public List<int> intCollection = new List<int>();
}
Comparison between C# and Bolt/UnityVS in the Inspector:
And in the graph:
Custom coding nodes is also possible and documented here for a regular node and here for an event node.
Both reflected nodes and custom coded nodes are pretty close to regular C# code performance wise and don’t incur the regular UnityVS perf hit for the most part.
Besides variables you have to determine the performance intensive parts of your game using Unity’s Profiler. Then you have to optimize that. Update, especially UnityVS update is incredibly performance intensive. Typically you want to keep Update() to a minimum. If something does not happen every single frame, it doesn’t have to be in Update. Use UnityVS custom events instead.
And if it can’t be optimized in UnityVS, rewrite the logic to C# scripts, then expose that code to UnityVS graphs. Or switch that part of the code to C# entirely.
1 Like
Hello,
Thanks, in the profiler here is the line consuming the most :
Is this only Update statements?
Thanks
1 Like
Yeap, it’s 8 Update calls per frame (and the logic inside the update). And it looks like Update might be marked as a coroutine in the Graph Inspector? UnityVS coroutines can also impact performance considerably and typically coroutines wouldn’t be in Update at all since Update resets anything in it every frame.
EDIT: Consider closing the Graph editor window for better performance. It can be taxing in the editor. Performance in builds is much better in general.
Unity are working on a new, much faster runtime that’ll drop sometime next year. Hopefully we don’t have to be so performance conscious for long.
2 Likes