LabVIEW
What is the Fastest producer consumer method. Queue, RT-FIFO, Event
Solved!
Hi all,
Another curly question for the pro's:
I have recently inherited some labview code that uses RT-FIFO for the transfer mechanism in the producer consumer architecture.
The code was first written 3-4 years ago and is presently in LV8.6. It is possible that the reasons for the architectural decision no longer exists.
I am skilled using a queued producer consumer architecure,
I understand the RT-FIFO Architecture.
I have begun using a user Event Based architecture.
(I have attached samples of each)
I also see the existance of a priority Queue
Each method has it's own capabilities and deficiencies, That aside, does anyone know the relative performance of each method.
(Assuming single process)
I would expect RT-FIFO to be fastest, it appears to be a low feature version of a standard queue.
What is the perfornace hit for using a more coding freindly Queue
The RT-FIFO description speaks of commications between time critical and lower priority threads.
Until today, I believed that Queues had the same capability.
I have included an event method I commonly use for peer review and to help to fellow users..
It allows:
1. Multiple producers with different data types
2. Processes repecting order of production.
3. Allows for asynchronus checking of functional notifiers such as stop, start and abort.
4. In a non real time system it can include front panel interactions.
What I don't understand about it is what overheads, or thread priority changes that may be experienced by using this architecture (it solves a lot of problems for me).
Thanks in advance,
Are you running into a situation where the difference in time between producing an event, and consuming it, is actually causing your problems? If not, this is not a question worth worrying about. Use whatever is most appropriate for your application.
There's no need to make wild guesses - build a VI, benchmark and test! The attached is a reasonable starting point, although I think the event structure may be slow due to setup time but may respond quickly once running. If you experiment with this, you'll probably find that there's no definite answer to which is fastest. Changing the size of the RT-FIFO, or of the queue, makes a big difference in speed. At least in my testing, a single-element RT-FIFO is fastest, but an infinitely large queue is faster than a small queue, and a longer RT-FIFO is much slower than the single-element version.
It's important to realize that RT is not another word for Fast or Efficient, it's another word for Consistent. For the purposes of real-time (deterministic) execution, it doesn't matter how fast the RT-FIFO functions are so long as they execute in exactly the same amount of time, every time (with the exception of a "forever" timeout value, of course). You can use either a standard queue or an RT-FIFO to communicate between loops. One use for an RT-FIFO is when a time-critical loop is enqueuing the data. It guarantees that the amount of time needed to put data into the FIFO will not vary. Enqueueing data in a standard queue will sometimes be faster than other times, depending on whether there is already space available in the queue or space needs to be allocated for the new element. If this variation is unacceptable, then use an RT-FIFO; otherwise, the standard queue works just as well.
If the architecture shown in your image is working for you, I don't see any reason to change it.
EDIT: oops, almost forgot to attach the code I used for testing!
