Poor Editor Performance on latest

Forums 💬 NodeCanvas ⚙️ Support Poor Editor Performance on latest

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #16766
    sinzer0
    Participant

      I’m on the latest everything unity 2019.1.1 and latest node and flowcanvas from store with flowcanvas integration from downloads.

      I noticed the flow and nodecanvas editors lock up regularly now.  Simply moving the nodecanvas window or dragging a wire is enough to lock it up.

      The older version (2.90) I upgraded from worked without hitches.  I’m on mac if it matters.

      #16781
      sinzer0
      Participant

        Just to update on this it seems if I minimize unity and leave the graph editor open then the performance issue with nodecanvas goes away.  On my laptop the graph editor sits on top of unity and I think that causes unity to constantly repaint the scene (just my guess).   But this did not occurr on older versions so maybe its 2019 that something has changed in  unity editor.

        #16780
        Gavalakis
        Keymaster

          Hello,

          Thanks for the information. I will take a look at this shortly, but one thing that could be happening is Unity re-serializing the graph every frame. This can happen if you have a graph asset selected (unity calls OnBeforeSerialize every frame on the inspected object in the hierarchy). Can you please try deselecting everything in the Unity hierarchy and notice if there is any difference?

          Thanks!

          #16779
          sinzer0
          Participant

            The hang up still occurs if nothing is selected in the hierarchy.  I did notice the issue only occurs with the scene or game view tab as the active tab.  If I select the asset store tab then it never hangs.

            #16778
            Gavalakis
            Keymaster

              Hello again,

              Sorry for the late reply.

              Hmm. Can you please open up GraphOwner.cs file and temporarily comment out the whole method named “OnDrawGizmos” in line #354 just to confirm that this is (or is not) the cause?

              Also, what kind of hang up is it? Does it occur on some certain situation after some specific action you perform in the editor for example?

              Let me know.

              Thanks!

              #16777
              sinzer0
              Participant

                I commented out that method and it did nothing.  Here is a gif that might help: Hangup Gif

                 

                In the gif i am continuously moving the window in  a circle anytime you see the cursor moving ahead and the window not moving is a 1-5+second hangup.

                 

                It happens when doing anything with the nodecanvas editor sitting on top of the Unity editor with either the scene or game view selected.

                 

                If i minimize unity editor then I never experience the hangup.

                #16776
                Gavalakis
                Keymaster

                  Hello again,
                  That indeed looks werid :/. It honesly works without any hang up here even with a lot more nodes/tasks than you have here. I just tested on Unity 2019.3.0a2 by the way with your setup (having the Graph Editor on top of Game or Scene View).
                  You said that previous version 2.9 worked without these hang ups. I will need to check every change I made from 2.9 just to see what could potentially be causing this on Mac.

                  Thank you.

                  #16775
                  sebjf
                  Participant

                    Hi,

                    I have the same problem on Windows. Unity 2019.1.7f & 2019.2.0b7 with NodeCanvas 2.9.2. The workaround of hiding the Scene and Game tabs does not work for me. 2019.3.0a8 crashes when opening, and I can’t downgrade to 2018.

                    Trying to deep profile the editor uses up all the memory on my PC and forces me to kill Unity.

                    I only just purchased NodeCanvas, where can I get a copy of <2.9?

                    Sj

                    Edit:

                    I can’t deep profile but I have placed Profiler calls around. Out of a period of ~300 ms, 100 ms is taken checking if nodes are hidden (Editor.Node.cs, ~ln 240) and ~77 ms drawing the minimap (GraphEditor.cs, ~ln 538). The remainder of the time is spent drawing the connections (Editor.Node.cs ~ln 258). If I comment out the minimap and hidden checks, the time spent drawing connections increases.

                    (~ln because I have placed editor calls so numbers may be off by a few)

                    #16774
                    sebjf
                    Participant

                      I have continued and found  the connection drawing code also makes “hidden” checks, and it is this code that is responsible for the slowdown (Editor.Node.cs ln 104).

                      As a workaround I return false right at the start of the get method (my client and I are just getting started so are unlikely to hide things for a while I think!), and the canvas runs fine again.

                      (PS. I didn’t mention before, I am using the Dialogue Tree)

                      #16773
                      Gavalakis
                      Keymaster

                        Hello,

                         

                        Sorry for the late reply.

                        Thank you very much for the information! I will take another look at possibility to increase the check performance. Right now it is of course done recursively (upwards), but this can of course lead to a big recursion (especially in Dialogue Trees!). If I can’t find a way to increase the perormance of that, I might just as well remove the feature altogether, but hopefully not 🙂

                        Thanks again for the information!

                        #16772
                        sinzer0
                        Participant

                          I tried the above change to Editor.Node.cs but it made no difference for me on the latest everything.

                          #16771
                          Gavalakis
                          Keymaster

                            Hello,

                            The posted issue above @sebjf stated, is only really relevant when there are a real lot of child nodes, meaning a very deep node tree, which is generaly easier to take place in Dialogue Trees. Do you also experience such slowdows that @sebjf stated?

                            #16770
                            sinzer0
                            Participant

                              [quote quote=14451]Hello, The posted issue above @sebjf stated, is only really relevant when there are a real lot of child nodes, meaning a very deep node tree, which is generaly easier to take place in Dialogue Trees. Do you also experience such slowdows that @sebjf stated? [/quote]

                              I was referring to the issue in my original post on this thread.  I don’t use dialogue trees.

                              #16769
                              Gavalakis
                              Keymaster

                                Hey,

                                Sorry for the late reply.

                                I am honestly not able to make the editor lock up. With that said, the only case that I found could cause this, is if you are editing a prefab DIRECTLY via the “EDIT BEHAVIOUR/FSM” button of the inspector of the prefab GraphOwner instead of opening up the Prefab first via the “OPEN PREFAB” button in the inspector that Unity has (at the very top of any prefab inspector).

                                I need to remove the “EDIT BEHAVIOUR/FSM” button from the inspector if it is a prefab that is not opened in the Unity prefab editor first.

                                Is that indeed the case for you by any means?

                                Thanks!

                                #16768
                                sebjf
                                Participant

                                  Hi,

                                  [quote quote=14431]Thank you very much for the information! I will take another look at possibility to increase the check performance.[/quote]

                                  You’re welcome!

                                  I have found another performance issue. When I interact with nodes at the bottom of a somewhat deep tree, the editor will appear to lock up.

                                  I found in the profiler that Editor:BeginWindows() was making millions of heap allocations on the mouse up event, and that they increased with tree depth. The allocs themselves took nontrivial time, but the big problem was when the GC would kick in and lock the editor for seconds or minutes.

                                  E.g.
                                  19281  allocs for node 6
                                  134774 allocs for node 7
                                  943225 allocs for node 8

                                  Since only one call was made to the window delegate according to profiler and that method is used lots of places, obviously they aren’t all actually happening in that function! I tracked them to the TrySortConnectionsByPositionX method, and found that it was recursive. If I comment out the call to the source connections performance is restored.

                                  This tree while not that deep has many nodes with many (7) output connections, so perhaps that is why it shows up here as opposed to on deeper but narrower trees.

                                  My fix for now is to make the function recurse only one level. This seems to maintain the expected behaviour when nodes are moved around, though its likely not as robust.

                                Viewing 15 posts - 1 through 15 (of 16 total)
                                • You must be logged in to reply to this topic.