topic Re: adding an unconnected node to a graph causes slow down? in Bifrost Forum

adding an unconnected node to a graph causes slow down?

Anonymous — Tue, 25 Feb 2020 17:06:32 GMT

im adding nodes to my graph without connecting them up yet and each time i do this i get a big slow down. Why is this? if the data flow of the graph doesnt change why is it being slow?

Re: adding an unconnected node to a graph causes slow down?

Anonymous — Tue, 25 Feb 2020 17:55:25 GMT

also adding a watchpoint is slow

Re: adding an unconnected node to a graph causes slow down?

Christoph_Schaedl — Tue, 25 Feb 2020 18:55:23 GMT

Most important Bifrost Shortcut.

Ctrl+ does pause the Graph.

Re: adding an unconnected node to a graph causes slow down?

Christoph_Schaedl — Wed, 26 Feb 2020 05:52:34 GMT

Shortcut is Ctrl + .

https://help.autodesk.com/view/BIFROST/ENU/?guid=Bifrost_Common_build_a_graph_pause_graph_html

I tried to edit my post above but my slow internet messed it up.

Re: adding an unconnected node to a graph causes slow down?

mjcg91 — Wed, 26 Feb 2020 06:19:56 GMT

Not sure about it, but seems like since 2.0.5.0, adding unconnected nodes triggers the graph's recompilation.

Re: adding an unconnected node to a graph causes slow down?

syracoj — Wed, 04 Mar 2020 13:09:51 GMT

When setting an envVar to see when the graph recompiles I am not seeing recompilation at node creation time.

But that doesn't mean there isn't a case where it is happening.

Could I have the scene file you were working with when encountering this along with a short list of nodes you were creating that seemed to be slowing things down please?

Re: adding an unconnected node to a graph causes slow down?

syracoj — Wed, 04 Mar 2020 13:17:06 GMT

What makes you say this Maxime? Is it just because of the performance degradation you are experiencing?

Re: adding an unconnected node to a graph causes slow down?

syracoj — Wed, 04 Mar 2020 13:48:06 GMT

hmmm....

perhaps I have found a case where a new node created is triggering a recompile.

Will talk to dev today.

Re: adding an unconnected node to a graph causes slow down?

mjcg91 — Thu, 05 Mar 2020 01:43:34 GMT

In a large graph (like a simulation solver setup), when getting a new node from the tab menu, it takes ~1 second to see the node appear, whereas in a clean graph, the node appear instantly.

I saw some case where it takes even longer, but I was not able to reproduce this.

Re: adding an unconnected node to a graph causes slow down?

syracoj — Fri, 20 Mar 2020 20:07:44 GMT

@Anonymous

@mjcg91

We have found a couple cases where graph recompilation is occurring.

Do you guys by any chance remember which nodes or compounds you were creating when you noticed the slowdown?

The two cases we identified have been logged. Just wanted to pick your brains on which nodes you guys experienced this with (if you can remember) so as not to miss something.

thanks.

Re: adding an unconnected node to a graph causes slow down?

mjcg91 — Sat, 21 Mar 2020 05:39:46 GMT

I think it might have been a basic math node like add or multiply, but honestly I can't remember.

Re: adding an unconnected node to a graph causes slow down?

wuhailu — Sun, 22 Mar 2020 01:28:21 GMT

My scene has a simple terrain deformer, but whenever I create an unconnected complex composite node, the Bifrost engine will be triggered.

Re: adding an unconnected node to a graph causes slow down?

syracoj — Mon, 23 Mar 2020 12:54:51 GMT

@wuhailu

what do you mean by composite node?

I see you have a create_mesh_plane. I identified that graph gets recompiled if a create_mesh_* gets created (even if it's not connected) in the bifrost graph so you might be encountering the already understood case. I'll rebuild your graph none the less and see what happens.

thanks!

Re: adding an unconnected node to a graph causes slow down?

syracoj — Mon, 23 Mar 2020 14:00:28 GMT

@wuhailu

I was able to encounter several situations where the graph recompiles even on a scene that has a create_mesh_plane simply connected to the output node. I talked to dev and they have confirmed that this is the same underlying issue with our already logged issue. So we should be fixing this shortly. thanks.