Hi,
I saw various posts about performance, so I'll turn my question as this:
Performance-wise, what is the overhead of Node-red (not using the web interface) vs a Node.js application ?
Thanks !
Hi,
I saw various posts about performance, so I'll turn my question as this:
Performance-wise, what is the overhead of Node-red (not using the web interface) vs a Node.js application ?
Thanks !
Significant!
Node-RED isn't designed for maximum performance but rather to make it easier to have a data-driven set of processes with minimal code.
So it carries a LOT of baggage around with it.
But having said that, it still runs happily on a Pi Zero So while the overheads compared to writing something in native Node.js are significant, in the great scheme of things, this is often not that important. Node-RED can still process a fair bit of data quickly even on a limited platform.
But it isn't probably the tool to use if you need to process and restructure inbound 70 million COVID records (you have have seen the debacle of someone in the NHS using an old version of Excel to try and do that as well - with all too predicable a result).
Node-RED excels at prototyping and handling the thousands of transient records that a typical home automation system will generate. It allows you to quickly build logic without having to worry about the scaffolding or too much of the detail (at least to start with). For those tasks, raw performance is generally not an issue.
Once you have your logic correct, you can always look for hotspots later and then optimise just those parts if you need to.
Well - as Node-RED is written in node.js then it is performing as a node.js application does
but as usual the answer is it all depends... Yes there is overhead - but most of the "baggage" Julian refers to is around the environment and editor and things put in place to help the user. If you are doing a simple http endpoint - transform the data and reply then the code path is not much more than you would have for a node.js app - if you used express (as we do), some middleware to handle cookies, follow links, authentication etc, some javascript to process it and reply. Of course if you write it with bare code then you may not use all the pieces we have so it will be faster. So it will of course depend on the complexity of the flow and what you are processing.
And just like any coding tool there are ways to write applications that are more efficient and ways make them real poor. No doubt there are improvements that could be made to various nodes to improve performance as well - but that needs someone with time and effort to hunt down and fix...
Most of the obvious deficiencies are around streaming data, as most nodes are written to expect complete packets of data so you can end up with large objects being processed rather than streams.
Having said that we have seen systems handling many millions of messages per second (using very large processors of course). As Julian points out most of the time it is not an issue, correctness is normally more important as letting a computer chew on numbers is what they do. But yes sometimes you do have to go back and think I wonder if you can make that bit more efficient.
Thank you both for your detailed answers !
Indeed I was thinking of HTTP endpoints for a start, and because "it's Javascript everywhere" (quoting @dceejay ) it would be possible to compile/transpile a flow to a Node.js application (thinking of what the MIT App Inventor does to create Android applications).
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.