It happened to me a few times that the Knime UI ground to a near total halt, making me wonder “What’s going on here”?
As it turned out, I had the “Node monitor” window open and set to “Show table”. As I was clicking around in my workflow, the node monitor was trying and struggling to display the huge tables that this workflow was processing. It took me a while to realize what is going on. This happens to me once every few weeks. No drama, but someone else with the same issue may never find out what is causing the Knime UI to slow down.
I wish the Node monitor could be sped up somehow, or somehow be allowed to run in the background so that it does not slow down the UI. If this is not possible, I suggest making the default view of the Node monitor “Show variables”, which does not have this problem.
To help me create an enhancement ticket, on which version of the KNIME analytics platform did you have this issue? Also what is the nature of the table(spec)?
I have tried on the latest AP (4.3.3) and couldn’t reproduce. I used the Test Data Generator node with 100k rows and the node monitor was pretty performant.
The table consists of 72 rows and 6 columns of the type “List (Collection of: Number (double))” and a regular String column.
The number of elements in these lists are as follows:
Column 1: 10639
Column 2: 41
Column 3: 436199
Column 4: 142986
Column 5: 1
Column 6: 142986
The rows represent biological samples. The lists are spectra acquired from these samples.
On my PC the node monitor needs about 22 seconds to display this table, during which the whole KNIME UI is unresponsive.
I am also running Knime 4.3.3. My OS is Ubuntu 20.04. My PC has an Intel i7-10710U with 6 cores and hyperthreading. Memory: 64 GB of RAM; 24 GB have been assigned to the Java heap space in the knime.ini file.
I have created an enhancement ticket (#AP-16974 for internal reference).
A workaround for now, would be NOT to have the Node Monitor view active when clicking around. As long as you don’t have Node Monitor view open you shouldn’t experience the delay because of it.
I almost always set the Node Monitor to “Show variables”, because I mostly use it for tracking loop execution. In this mode there are no freezes because there are no huge lists to show. But the default mode of the Node Monitor after every Knime startup is “Show table”, which sometimes leads to confusing behavior (namely unexpected freezes).
Therefore, another way to partly solve the problem would be if Knime would store the last-used Node Monitor view settings.
I have a widescreen monitor (3840x1600 resolution) and when using KNIME in a maximized view, the Node Monitor window takes a very long time to paint/refresh when I click on a new node. I’ve attached a video showing the refresh time when clicking on a node that has lots of columns in the output. Note how it paints each column sequentially, and on the wide screen it takes (what seems like ) forever, since it has to finish refreshing before you can do anything else in the KNIME window.
For instance, if you want to configure the node by double clicking on it, you have to wait for the desktop to refresh the Node Monitor before your double click is registered. Or, if you want to see the right-click context menu for a node, you have to right click on it, and while waiting for the Node Monitor to refresh, you have to leave the cursor hovering over the node or else when the Node Monitor refresh finishes, the right click will register wherever the cursor is now, not where it was originally clicked.
Is there anything that can be done to speed this up? I want to have the node monitor open all the time so I can quickly see my outputs without having to look at the context menu view of the node’s output.
I have a Dell Precision 5540, i9, 64GB RAM with a Quadro T2000 GPU on Windows 10.
I have submitted a ticket for improvements (#AP-16974 for internal use).
For the time being, a workaround would be to click around without the Node Monitor view active. You shouldn’t encounter the delay as long as the Node Monitor view is not open.
