[low priority] Do not hook onNodesChange but on one of the selection events

[pmrv]

We use this hook to update the selected nodes list and to push nodes JSON to the python side.

The latter is problematic, because the callback is called on every move a user makes while dragging a node, and dumping the json this often is performance relevant and makes workflows with more than ~10-ish nodes feel sluggish.

[pmrv]

Still causes performance issues even after #108, this time on parsing JSON. Not sure why, because dragging nodes should not send new data to the model, but I'm guessing on of our event handlers writes inadvertedly to model.nodes.

Flame graph from firefox

[Tara-Lakshmipathy]

Don't know if it's just me, but the widget also becomes very sluggish after a period of inactivity even with 3-4 nodes in the workflow. Starts working like normal again after I restart kernel. So, I wonder if it's the events that is causing the slowdown or just the jupyter kernel. I'll post my flame graph when it slows down next.

[pmrv]

I had that feeling too. Would be good to test also whether restarting the kernel is necessary or if just reinstantiating the GUI is sufficient.

[liamhuber]

Don't know if it's just me, but the widget also becomes very sluggish after a period of inactivity even with 3-4 nodes in the workflow. Starts working like normal again after I restart kernel. So, I wonder if it's the events that is causing the slowdown or just the jupyter kernel. I'll post my flame graph when it slows down next.

Ayayay, I am sad to hear this... there is no kernel restart built into the GUI itself, so this is going to cause a headache for web portal users accessing the tool as a Voila app.

[Tara-Lakshmipathy]

OK, a small update: reinstantiating the GUI fixes the sluggishness after a period of inactivity but I don't think it is the same sluggishness as the one @pmrv experiences with large workflows. Or maybe it is, not sure...

Here it is after a period of inactivity: very sluggish and laggy

And here it is after re-instantiating the widget:

My firefox performance profiles:

• Performance profile before re-instantiation: https://share.firefox.dev/3QYfYuo
• Performance profile after re-instantiation: https://share.firefox.dev/3DxyU08

[pmrv]

In your first profile the biggest contribution is still from JSON.parse. I think we only call it on model.get in widget.jsx and one more time in CustomNode.jsx. Two spikes are within calls to updateNodePositions, so I'm guessing those are event handlers. The biggest one is also in an event handler it seems, but also within a useState. I'm guessing we're updating something in react in a strange way that triggers a bunch of normal events. I don't really know my way around react though.

[Tara-Lakshmipathy]

When comparing my two profiles, the events 'updateNodePositions' and 'triggerNodeChanges' are about 5x slower before re-instantiation. But I'm not sure what it has to do with a period of inactivity and why it gets solved after re-instantiation.

As for your slowdown with larger graphs, I'm really not sure after you moved the JSON.stringify stuff to trigger after moving the node. Maybe moving a node also counts as an edge change because the edge changes shape? I would be very surprised if it does.