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.
