From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-07-2021 02:55 PM
Hi,
I made a VI which counts the pulses from a quadrature encoder using the boolean crossing.vi and noticed very high CPU usage while the VI is running. A and B signals are received from the encoder which generates 0-5V levels using a cRIO with NI 9223 AI modules. I found that if I implement the logic behind boolean crossing.vi in my For loop, the VI execution speed increases by a factor of 60 and I could not explain why. It's expected to gain some speed if code from subVI is implemented directly in caller but that much? It seems that it makes a huge difference if I use two instances of the boolean crossing.vi or only one. Any thoughts?
I'm using LabVIEW 2018 SP1.
Solved! Go to Solution.
05-07-2021 04:20 PM - edited 05-07-2021 04:21 PM
I can't test the code at the moment, but I have seen similar effects so I am going to trust that you are seeing something real. It seems that when you put two of those VIs together with no dataflow dependence between them that you are generating a thread switch during execution. One way to test this theory is to place the two pt-by-pt functions in the first image inside consecutive frames of a flat sequence structure, or otherwise introduce a fake dataflow dependence between the two VIs. See if you measure a significant improvement in performance.
05-07-2021 04:29 PM
@Darin.K wrote:
I can't test the code at the moment, but I have seen similar effects so I am going to trust that you are seeing something real. It seems that when you put two of those VIs together with no dataflow dependence between them that you are generating a thread switch during execution. One way to test this theory is to place the two pt-by-pt functions in the first image inside consecutive frames of a flat sequence structure, or otherwise introduce a fake dataflow dependence between the two VIs. See if you measure a significant improvement in performance.
I just tried making a copy of the VI and setting it to inline. Oddly this did not make any significant performance increase.
Also on a side note, the numbers are all slower on my PC which is kind of surprising. It is a pretty beefy machine. I have 16 cores with a base speed of 2.1 GHz (2 sockets) giving me 32 logical processors along with with 32 GB of RAM.
05-07-2021 05:37 PM
I haven't solved it, but I found something else fun...
If you enable edit mode on the Boolean Crossing VI, and change it from normal priority to a higher priority, the execution time goes WAY up. Like, it takes over 100 times longer on my setup (on the frame with the two copies).
However, if I set it to "Subroutine" priority, instead of taking 100 times longer it takes about 10 times less to run.
Not saying that changing the priority of a vi.lib file should be the way to go to fix it, but maybe it's a hint about what's going on? A fight for resources, maybe?
05-07-2021 06:17 PM
@Kyle97330 wrote:
However, if I set it to "Subroutine" priority, instead of taking 100 times longer it takes about 10 times less to run.
Subroutine priority forces the SubVI to run in the same thread as the caller, so this is further evidence that thread swapping is the performance bottleneck here. In fact, this setting forces the two calls to run single-file as if you had placed a dataflow dependency between them.