Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Visual scripting performance

Discussion in 'Visual Scripting' started by At09em, Mar 25, 2021.

  1. At09em

    At09em

    Joined:
    Mar 25, 2021
    Posts:
    5
    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?
     
  2. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    188
    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.
     
  3. BioBurden

    BioBurden

    Joined:
    May 28, 2018
    Posts:
    115
    What will this new backend do differently exactly?
     
  4. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,050
    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.
     
  5. BioBurden

    BioBurden

    Joined:
    May 28, 2018
    Posts:
    115
    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.
     
  6. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    188
    no boxing, no reflection, split the authoring and runtime data and a few more things
     
  7. BioBurden

    BioBurden

    Joined:
    May 28, 2018
    Posts:
    115
    Thanks for clarifying. That's awesome, and is definitely reassuring in terms of using it now, knowing that it definitely will get even better.
     
  8. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    188
    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)
     
  9. BioBurden

    BioBurden

    Joined:
    May 28, 2018
    Posts:
    115
    Oh wow, that's quite an improvement. Exciting stuff!
     
  10. merpheus

    merpheus

    Joined:
    Mar 5, 2013
    Posts:
    202
    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.
     
  11. SPNK78

    SPNK78

    Joined:
    Mar 8, 2021
    Posts:
    13
    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?
     
  12. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,050
    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:

    Code (CSharp):
    1. using System.Collections.Generic;
    2. using Unity.VisualScripting;
    3. using UnityEngine;
    4.  
    5. //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.
    6. [IncludeInSettings(true)]
    7. public class TestScript : MonoBehaviour
    8. {
    9.     //variables have to be public so that Visual Scripting can access them
    10.     public GameObject testObject;
    11.     public string testString;
    12.     public List<int> intCollection = new List<int>();
    13.  
    14. }
    15.  
    Comparison between C# and Bolt/UnityVS in the Inspector:
    upload_2021-7-30_21-4-18.png

    And in the graph:
    upload_2021-7-30_21-4-55.png


    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.
     
    Last edited: Jul 30, 2021
    nassy747 likes this.
  13. SPNK78

    SPNK78

    Joined:
    Mar 8, 2021
    Posts:
    13
    Hello,

    Thanks, in the profiler here is the line consuming the most :
    CPU.PNG
    Is this only Update statements?

    Thanks
     
    SurreyMuso likes this.
  14. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,050
    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.
     
    SurreyMuso and SPNK78 like this.