Yes, I am sure you are right, but nothing compared to the overheads of a browser running in a GUI.
You could try to let your python code do the I/O and just report rbe's (Report by Exception) via mqtt. Then you would have a "reasonable fast" I/O checking system below and a visualization on top that would be "fast enough for your eyes"
If I might chip in.
You could definitely cut some fat from this.
- Lose the contrib loop node (unknown factor and unnecessary)
- Use the faster unsafe function (less overhead as it doesn't use a VM)
Also, is there any reason why node-red couldn't be you first choice & if/when you need C like IO performance, you simply use a native binary to execute that part of a solution?
I've not yet looked at the code for that node, but if it sends anything to the ui, then I would guess it is not optimised in any way to handle rapid changes. IE I would guess it tries to send every change of state, rather than only sample them. It is very easy to saturate the websocket connection to the browser.
Hi @Colin,
The browser is not running on the Pi. The Pi does have a GUI active but it is not being used at all, not even logged in. Node-RED is started remotely over SSH and the browser is firefox on ubuntu on machine with 12 cores & 64Gig ram that is not particularly busy.
On the overheads situation I will try and implement suggestions from @Steve-Mcl on the unsafe function and that both of you made with respect to the contrib package and see what happens
I noticed node-red-node-pi-gpio uses a Python library to switch IO. I don't know what the performance implications of that are but it doesn't sound very optimized(?)
Does anyone happen to know if someone has built Node-RED nodes using pigpio for the switching? At least from personal experience it is very performant.
the browser may not be busy - but if it is showing status at all - either debug - or blobs under the gpio nodes - then the Pi will be feeding the websocket as fast as it can.
Thanks but I found this already. The pigpio module I linked is a wrapper to a C library called pigpio, so it might have nothing to do with the similarly named pigpiod daemon. 
Hi @dceejay,
I did spot that while I was coding this test up and I was concerned about load so I did deselect "show node status" under settings. Is this what you mean or are you talking about a different setting or startup configuration parameter?
Nice - if anyone fancied "upgrading" the existing GPIO nodes to use that - that would be a great pull request contribution... (of course would need to check if existing functionality can be maintained without breaking existing users... but it does look like a good library)
Thanks for the tip! It could be a fun way to contribute. I'll need to look into the current implementation if it seems like something I could pull off.
@dpnsw - yes that is what I meant.
On my Pi3 - If I just toggle the io pin as fast as i can - with no browser attached and no status etc I can do 50000 cycles in about 2.7 secs
2020-04-26T15:12:01.324Z
2020-04-26T15:12:04.019Z
(but I'm well aware this is not exactly a real world situation or useable)
True, but probably more directly comparable to @dpnsw's python program than the flow he posted. 50000/2.7 = 18.5 K/sec compared to 218 K/sec is a factor of 11, not unreasonable considering the baggage that NR and node.js have to carry.
Sorry but can't understand what you are evaluating here. So you want to do some gpio work, the more efficiently possible, and you are using SBCs and high level software tools?
There are zillion development boards, some of already with network connectivity, that could do this work way faster. They could cache readings and send to nr if measurement is what you need.
I suppose it's not the case, but here we say: (in dumb translation) A bigger donkey, walking or not.
Edit: Sorry, I wrote in response to the ops original question.
Many thanks to everyone that responded.
Just to clarify the purpose of this is to do a simple test that can be performed on every type of platform from microcontrollers, SBC and FPGA devices using different programming languages. I am not trying for real world, I am trying to understand a performance limitation. There is no point trying to sample an ADC at 20kHz on a Pi 3 using Node-RED (many thanks @dceejay ).
The test is to change state on a digital IO pin & measure to confirm it has changed state (meaning perform both a write and read) as 1 cycle and do that as fast as possible.
I ran the equivalent test on a BeagleBone Black WiFI using Python and also C. Is this a real world test, NO. Could I have done this a different way, YES. but to me that is not the point. The point is no mater what hardware or software combination I am using I am doing the same thing. Is the limitation hardware, software or something else. To me that is no so important I am looking for orders of magnitude differences. There is a Python library for the BBB WiFi from Adafruit and that gave me performance around 10K cycles per second. The equivalent C program clocked in at almost 850K cycles per second on exactly the same unit. I was surprised at the level of difference.
Interestingly an equivalent python program on the Pi Zero is capable of 30K cycles per second and if you cross over to a multicore Pi 3B+ the number increases to 217K (on a Pi 4 it is 530K). So it could be more library than interpreter Vs compiled.
Is any of this real world, NO of course not but nowhere can I find advice that if I use Python on a BBB for DIO it is going to be 85 times slower.
Similarly I had no idea coming into this what sort of performance to expect from Node-RED on DIO and now thanks to everyone here I do.
Many thanks for that.
1 Like
Hardware could also be a factor. The Pi Zero has 512M and runs at 1GHz while the pi 3 B+ has 1GB and runs at 1.4GHz and the Pi 4 has 1, 2 or 4GB and runs at 1.5GHz
1 Like
@zenofmud, the comparison was meant to be between the Pi Zero and BBB. Data on the Pi 3B+ or 4B was more informational. In fact if you look at the old Pi B it clocks in at 30K (54K if you overclock). My point is that it the 3x difference looks driver related between Pi Zero, Pi B and BBB. The hardware differences are more like 20 times when you jump from zero to Pi 3B+ with a move to multicore and 40 times when you jump to the Pi 4B.
Also the speed difference between Python and C on the same BBB is important to note.
On a pocket Beagle I can get 425K using C and under 1K with Node-Red
The data is just one item in a long list such as speed to deploy, maintainability, ease of use, hardware, software and driver support, size of community, target audience, etc....
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
