So, having cut back my 110 tabs on main Win10 PC Node-RED install to just the ones that I run 24/7, I'm thinking of splitting up some big tabs and using link nodes to other tabs instead to tidy things up and compartmentalise things a bit.
This is to make things easier when I come back in 6 months and think - what's this thing do 
Just checking to see if it makes a diff to Node-RED whether a link goes to a different tab or the same tab?
Does having the same number of nodes but spread over more tabs make a diff?
Does increased tabs need for more resources on the editing browser?
[warning - much speculation follows]...
I would guess the introduction of link node WILL have an affect (server side) - but in the grand scheme, this will barely be noticeable. (I'm gonna do some tests on this later to try and quantify it)
I have read a few times (on this forum) of slow browser performance - where the OP had loads going on in a heavy single TAB - so you may actually perceive a (client side) improvement if you do split things across TABs
I think Dave and Nick will be able to provide a more scientific answer.
I dont know the architecture behind node-reds implementation of TABs but I suspect the affect (of more TABs) is less than rendering lots of nodes on 1 TAB.
For clarification - I already have the link nodes on the same tab to route messages around the various flows - this is about performance/resource change if they are moved to different tabs.
I'd agree with these speculations. I'd like to add that I would be very surprised if a link to another tab would be any slower than to within a tab performance wise.
I've noticed even a bigger browser window (visible area) to a busy tab takes more resources from the browser. So splitting things to tabs will make the editing experience snappier. Given that, if the browser is running on the same machine this could also affect the performance of the runtime.
1 Like
Ah, right. Well - My strong suspicion is (at server side) this will have zero (additional) affect.
Basically correct all round. The runtime has no concept of tabs - it just passes messages from one node id to another node id. Obviously adding any link nodes at all will add a small effect as the message passes through two more nodes, but they are just ticks on the event loop with no major processing.
On the editor side - adding lots of nodes does have an effect - as whenever you interact with the page it has to check for changes, resizing, collisions etc and that can often necessitate checking across all nodes on that tab - so the "foreach" loop grows bigger... which can slow things down - but this is browser side so most laptops cope fine. Though I think in the 1.0 timeframe Nick has (and still is - especially now with groups) been looking at this and optimising this somewhat to help improve it... - but yes - net is while editing multiple tabs may be better in very busy, flows but have little effect on runtime.
4 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
