Performance issue when lots of typedinputs

Hi folks,

@Steve-Mcl and I developed last year the node-red-contrib-ui-svg node, but seems we have a performance problem for larger drawings. I managed to solve one of the causes, but now I'm stuck with the large number of TypedInput fields that are being used:


Appears this is a known problem in Node-RED, but the core nodes workaround it (in a way that we cannot do).

When I use the profiler of my Chrome developer tools, I see lots of resizing calculations for all the TypedInput's:


Which is being triggered for every TypedInput that we add, via addItem:


Since we call the addItem lots of times for large drawings, this will cause a lot of resizing.
Think it would be solved if the resizing was only done once at the end, but I assume that isn't possible.
But this is becoming a bit too complex for me :pleading_face:

Is there anybody who has an idea how we can solve/workaround this?

Thanks a lot!!

A couple of ideas Bart (but they don't fix the typedinput issue you're seeing)...

  1. Replace the individual elements with a table and an edit button column that enables the row for editing and then shows a newly created typedinput. (So only one in memory/on screen at a time)

  2. A more simple list with edit button that pops up an edit dialog.

Neither are ideal but should work.

Tbh, I'm seeing lots of nodes with this type of list - it would be fantastic if a grid like editor was built in (like configTable or something)(is there something like this already?). Ps, I'm not asking any Dev to dive on this - just that I'm seeing a pattern and tbh, setting up these lists are a bit of a pain. Alignment issues, sizing issues blah blah.

1 Like

Hey Steve,

That are indeed possible workarounds. My gut feeling says that it would be very difficult to solve the root cause in the core of Node-RED, so I might have to go that way ...

In this particular case, the caller can also workaround it by adding less items to the table (by using CSS selectors). But in the near future, there will be drawings that run into problems anyway. So we should solve it one way or another.

Lots of refactoring again ...

Do they absolutely need to be typed inputs ? I know they are useful but would plain text be OK for most cases ?

Hey Dave,
the inputs are being used to specify the content of the output message (which can be boolean, number, text, ...):


So would be stupid if I had to go for plain text input fields ...

Well of course you don’t have to. But you have a performance problem so it’s your trade-off. I think Nick is aware of the issue but somewhat busy (as ever)

1 Like

Will try to find a workaround...

FWIW, I've spent an hour today changing the TypedInput to use flexbox css which means I have been able to remove all of the expensive code we had for resizing - it is all now handled by the browser's native CSS handling which is a much better place for it to be. Have tested across Chrome, FF, Safari and even IE11 and it all looks good.


That's excellent Nick.

Will save me (Bart :wink: ) some major refactoring.

Can you guess the next question?

What Is the Airspeed Velocity of an Unladen Swallow?

I imagine 1.0.5 will be arriving the near future. A few useful fixes have gone in recently.


Nick, very kind of you to have a look at this issue! Thanks!!

Hi Nick (@knolleary),
Just confirming that indeed version 1.0.5 fixes this problem very well!
While the previous version of this particular SVG node's config screen (of a large SVG with lots of typed inputs) took more than 15 seconds to load, now it only takes maximum 3 seconds.
So nice job again! Thanks !!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.