Question Performances issue when several IMGUIContainer

Hi,

I'm using Unity 2020.1.1f1 and I'm making a node system UI based on UIElement GraphView.
I have a graph view, which contains Nodes. Each node contains an IMGUIContainer.
I understand that using IMGUIContainer means not taking fully advantage of the new UI system but it's a limitation I have to ensure compatibility with preexisting UI logic.

So I noticed performances were rather bad when the number of nodes increase.
When moving the graph view for example. Maybe someone could give me some tips to avoid this problem ?

Though, after investigating, the problem seems to be related to the property "worldTransform" and the method "UpdateWorldTransform" of the class VisualElement.


By looking at the source code of VisualElement I isolated two issues :

1)

Code (CSharp):

1. public Matrix4x4 worldTransform
2. {
3.     get
4.     {
5.         if (isWorldTransformDirty)
6.         {
7.             UpdateWorldTransform();
8.         }
9.         return m_WorldTransformCache;
10.     }
11. }

Looks like moving the graph view is making all the children elements (so nodes) world transform being dirty.
Seems coherent, but I wonder if there is not a way to avoid that ?
I tried to specify UsageHints property without success, I don't know if this really has something to do with my problem.

2) Matrices operations seems to have a non-negligible impact on performances.
I wonder if Unity already thought about optimize these operations for critical path ? (like this one where we can quickly get hundreds of multiplications).
I already did this once for my own code, using methods with ref Matrix to avoid useless copies of Matrix4x4 (which is a struct) when using * operator. And if I remember correctly I was quite satisfied with the result.

 

Hello Antoine,
Thank you for your quick reply, I appreciate.

There are exactly 439 nodes in my graph example (made just for the stress test).
Here are the measurements without deep profile :


My graph support unzooming yes. I thought about simply hiding IMGUIContainer when there are too much nodes visibles at the same time (which also probably means GUI is too small to be readable anyway). What would you suggest to check if a VisualElement is visible on screen ? And to disable IMGUIContainer ?
Actually I'm checking if node worldBound is overlapping with graph view and insert/remove IMGUIContainer from hierarchy according to that (disabling IMGUIContainer doesn't seem to work). But maybe there are more easy/optimized way to do that ? Especially knowing that IMGUIContainer has now a cullingEnabled property (which is curiously set to false by default).

 

Culling was already enabled since the first post.
My profiling screenshots are made when viewing all the nodes. It is important for me to keep the editor smooth in such case, as it's common to unzoom a lot just to navigate through a big graph.

I forgot to specify one thing, the issue is completely related to IMGUIContainer.
Here is the same graph, same view (all the nodes), deep profile. I just removed the IMGUIContainer inside each node :


Note 1 : you can still see IMGUIContainer in the profiling data, it's just because I have one used to draw a toolbar for the graph view (so independent to the number of nodes inside the graph).

Note 2 : the source of the problem would be RencerChainCommand.ExecuteNonDrawMesh method, which seems to be called for each IMGUIContainer in the hiearchy (called 448 times in the screenshot of the initial post).

Note 3 : the big spikes you can see on the profiler screenshot are related to garbage collector. I selected a frame not affected by the GC to make the screenshot.

Reminder : problems happens even when IMGUIContainer draw nothing.

Why having empty IMGUIContainer in the hiearchy generates such an overhead ?

 

Yes

Thank you for the details. That's what I feared unfortunately.
In my case the bottleneck seems to be on the transform computation.
But there doesn't seem to be a lot of solutions in this case... Optimizing UpdateWorldTransform doesn't seem easy for the general case (except micro-optimization like what I suggested for the matrices operations).
Did you thought about wrapping the core logic of UpdateWorldTransform into a GetWorldTransform method that could be overridden ? I guess it doesn't really make sense if it's only useful for an isolated case like mine :/.

 

Okay, I totally understand. Thank you for all the replies.