NodeCanvas Forums › Support › Poor Editor Performance on latest
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.
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.
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!
Join us on Discord: https://discord.gg/97q2Rjh
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.
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!
Join us on Discord: https://discord.gg/97q2Rjh
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.
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.
Join us on Discord: https://discord.gg/97q2Rjh
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)
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)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public bool isHidden { get { if ( graph.isTree ) { for ( var i = 0; i < inConnections.Count; i++ ) { var parent = inConnections<em class="d4pbbc-italic"></em>.sourceNode; if ( parent.ID > this.ID ) { continue; } if ( parent.collapsed || parent.isHidden ) { return true; } } } return false; } } |
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!
Join us on Discord: https://discord.gg/97q2Rjh
I tried the above change to Editor.Node.cs but it made no difference for me on the latest everything.
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?
Join us on Discord: https://discord.gg/97q2Rjh
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?
I was referring to the issue in my original post on this thread. I don’t use dialogue trees.
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!
Join us on Discord: https://discord.gg/97q2Rjh
Hi,
Thank you very much for the information! I will take another look at possibility to increase the check performance.
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
public void TrySortConnectionsByPositionX(bool recurse = true) { if ( !Application.isPlaying && graph != null && graph.isTree ) { if ( isChecked ) { return; } isChecked = true; outConnections = outConnections.OrderBy(c => c.targetNode.rect.center.x).ToList(); if (recurse) { foreach (var connection in inConnections) { connection.sourceNode.TrySortConnectionsByPositionX(false); } } isChecked = false; } } |