Extreme high UI latency

Hi,

working on the latest data challenge I am processing the data using the Parallel Chunk nodes. Nothing special as I am using them almost on a daily basis.

Though, I noticed an extreme UI latency despite having enough system resources available. Please see my screen recording (download).

I can work with the situation and will share the workflow once I have completed the challenge.

Updaate
I believe I figured out what is happening or at least have a good suspicion:

  1. Some CPUs are highly utilized but not all
  2. The UI lag is triggered upon parallel execution indicating that UI rendering is happening using CPU instead of GPU
  3. The rendering process is done on one of the heavy utilized cores causing congestion

The problem I see here … I utilized all cores before in even more demanding processes like web crawling with +10 sessions all while crunching data in another workflow but without any perceived UI lag.

This issue also appeared only with the latest update of Knime or any of it’s extensions. I am doing nothing fancy or totally new either.

Best
Mike

Here is another example where the CPU constraints become visible too:

Checking the task manager two processes caught my attention “Equo Chromium Helper” and “System”, both utilizing the GPU significantly

Trying to close the eCharts window made Knime unresponsive and it only recovered after about a minute or two.

4 Likes

Hello @mwiegand,

Great to see your detailed documentation of the issue. I opened up a ticket previously in relation to performance, and I have went ahead and added a link to this thread under it also and added a +1 to it as they both relate to hardware not being fully utilized properly.

Ticket AP-22521

TL

7 Likes

I’ve reproduced this kind of today. killing “equo chromium helper” process solved it. Windows11 with KNIME 5.3.3.
scenario: while working an a workflow, with several other workflows also open in other windows, the CPU usage went over the roof suddenly. It made the UI lag too.

4 Likes

Hey @mishal153,

Thanks for reporting on what you did. I went ahead and added the work around you found to the ticket.

TL

1 Like

Hi @thor_landstrom,

I had something possibly similar with KNIME 5.4 today. The MUI has been very sluggish with a couple of workflows open, and switching between workflows or switching in and out of metanodes has been a continual series of waiting a good few seconds for it KNIME to switch.

I have also seen a high incidence of the KNIME 5.4 “unresponsive UI detected” message that offers me the opportunity to “save and restart” or wait. I haven’t had to restart, as waiting is sufficient, but the message keeps bugging me, and to be honest was getting quite annoying when it kept popping up as I waited for a workflow to run, and as far as I could see it wasn’t actually unresponsive. It was simply executing a loop. I’d clear the message and then maybe 30 seconds later the message popped up again.

Having decided to finally shut down KNIME to give the CPU some time off :wink: (the fan has been constantly running), I noticed that it made no difference to the fan noise, and opening Task manager I could see that a number of Equo Chromium helpers were still running. I thought I’d give it a chance to finish doing stuff, if that’s all it was but some 20 minutes later (as I write this), they were still there even after KNIME had long since closed.

Not only that, but they continue to consume a high percentage of my CPU (and the laptop fan, from the constant noise it’s making!)

I didn’t spot it at first but in fact I had also been running KNIME 5.3 at some point earlier today, and looking at the above screenshot you can see there are Helper processes for 5.3 still running too, with one of those also consuming high CPU. I’m guessing that this is why KNIME’s UI has been particularly sluggish all afternoon?

Another 5 minutes further on, and still they execute…

Does this mean these processes have simply crashed and I should have checked and put them out of their misery long ago? :open_mouth:

Are there any known issues (potentially external to KNIME) which might cause this to occur?

This is on Windows 10.

2 Likes

@takbb can you check whenever the utilization is on one core only? I noticed that this happened to me pretty much all the time. With the recent conversation amongst the start alliance about performance and our possible findings about MUI, I believe the culprit of any perceived performance regression is due to the poor multi-threading capabilities (under certain scenarios).

4 Likes

Hey @takbb,

Check out what @mwiegand suggests, I think including that on the ticket will be helpful if you notice it only using one core. I added another +1 to the ticket.

TL

2 Likes

Hi @thor_landstrom , when I next get a chance, and am experiencing the slowdown, I’ll take a look and report back what I find. Thanks.

Do I understand correctly that the slowdowns, particularly those with orphaned equo chromium helpers, have nothing to do with actually generating large images (as was the original context)?

1 Like

@BenjaminMoser, certainly in my case, it’s nothing to do with generating images, but I did see the orphaned processes.

1 Like

Since version 5.8, I have had the same problem with ‘equochro_helper.exe’. As soon as I open a workflow, the CPU usage exceeds 80%. However, I work on a remote computer, and the problem only occurs here.

Can anyone explain what equochro_helper is supposed to do? Maybe this could shed some light…

Hey @Marc_Goossens,

It is essentially the UI process that is responsible to render the workflow. We have recently changed the rendering from an SVG based approach (that works mainly on CPU) to a Canvas based approach (this can make use of the GPU of a computer). It turns out that the Canvas variant is really strong for large workflows if there is a GPU available, but it performs very poorly in scenarios where there is no GPU. Most of these remote scenarios either have no GPU available, which is why the performance feels not as good. For these cases I would recommend to go into the settings and change from the WebGL based rendering to the old SVG based rendering. We are currently trying to identify the use cases for such remote setups and trying to explore solutions for it.

What is your use case why you are using this remote setup?

Greetings,

Daniel

3 Likes

Hi Daniel and thanks for clarifying this…
I do not have a GPU available, so I will change the setting.
Don’t know if would be technically possible to auto detect this (availability of GPU) and change the setting accordingly?

Hey @Marc_Goossens,

let me clarify this. I am not taking about an external GPU that is now required. Most laptops come with an integrated GPU that should already be sufficient. Do you have no GPU available at all or just no dedicated?
As for your suggestion, something like that might be possible but maintaining both rendering mechanisms takes a lot of effort. In a beste case we find a solution to support both use cases without having to maintain two rendering techniques.

Greetings,

Daniel

Hi Daniel,

I have no dedicated ‘external’ GPU, not sure how to check if I have an integrated one.

I understand your point about having to maintain 2 different rendering techniques and very likely in the near future almost everyone will have some form of GPU available.

For the moment, I will play around with the setting and see which one works best - it is not a big issue for me (and maybe ask Father Christmas for a GPU board…)

Again, thanks for clarifying this issue.

Switching to ‘SVG rendering’ solved the problem. I work remotely on a hosted computer in the company.

1 Like