LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Notifier vs Queue processing speed

Solved!
Go to solution

Hi LV experts.

 

I was messing around with a project which uses both queues and notifiers for different display update tasks.

 

I noticed that when using a Queue seemed to be able to keep up with data processing faster than the notifier. At first I assumed this was because the notifier is lossy and was dropping some of the data. So I put together a quick (very contrived) benchmarking vi to test this. 

 

Turns out, at least on the pc i was running the code on (2015 alienware r2 laptop, intel i7 4710 cpu, 16GB ram) the queue is able to move the data much quicker. A couple of runs suggested somewhere between 7 and 9 times faster than the notifier, with at most 1 or 2 elements remaining in the queue at the end of the run.

 

My question then is, why the disparity? I assume their underlying implementation is quite different but is there somewhere I can learn more about the internals of these and other synchronisation mechanisms to better understand which to use when speed is critical?

 

Oldbhoy

0 Kudos
Message 1 of 10
(163 Views)
Solution
Accepted by topic author Oldbhoy

Well the main difference is that a Queue is designed for N to 1 lossless communications and a Notifier is designed for N to N lossy communications.  

 

While I can't say for certain, not seeing the underlying architecture, I suspect that the additional burden on the Notifier is because it does all of the extra internal bookkeeping involved in maintaining the current value in memory, maintaining timestamps of the notifier, and having the ability to cancel notifications after issuing them.

0 Kudos
Message 2 of 10
(158 Views)

While your comparison is interesting, I am not sure how it's relevant as Queues and Notifiers are two different tools for two different jobs.

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 10
(114 Views)

You're absolutely right, it was merely a curiosity on the underlying architecture and just to better understand why one would work much slower than the other.

 

As @Kyle97330 suggested, it's probably the extra bookkeeping processes required that contribute to it, which I hadn't fully considered

0 Kudos
Message 4 of 10
(85 Views)

I think your conclusion on performance is flawed.  You are just seeing how many elements got processed, not how fast the write-read is done.  With a Notifier, if another Notification is sent before that current is read, you lost that data and so it does not get processed.  A queue just adds the data to the FIFO so it can still be processed when that loop gets processor time.  If you change your indicators to to charts and just is the i terminal for the input of the Queue and Notifier, this should become more obvious.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 10
(82 Views)

Great, thanks. Will give that a shot

0 Kudos
Message 6 of 10
(80 Views)

@crossrulz wrote:

I think your conclusion on performance is flawed.  You are just seeing how many elements got processed, not how fast the write-read is done.  With a Notifier, if another Notification is sent before that current is read, you lost that data and so it does not get processed.  A queue just adds the data to the FIFO so it can still be processed when that loop gets processor time.  If you change your indicators to to charts and just is the i terminal for the input of the Queue and Notifier, this should become more obvious.


Would testing with a queue length of 1 be a more or less apples to apples comparison?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 10
(73 Views)

@billko wrote:

@crossrulz wrote:

I think your conclusion on performance is flawed.  You are just seeing how many elements got processed, not how fast the write-read is done.  With a Notifier, if another Notification is sent before that current is read, you lost that data and so it does not get processed.  A queue just adds the data to the FIFO so it can still be processed when that loop gets processor time.  If you change your indicators to to charts and just is the i terminal for the input of the Queue and Notifier, this should become more obvious.


Would testing with a queue length of 1 be a more or less apples to apples comparison?


So I tried this, and sure enough the margin of difference between the total number of elements processed drops significantly (Queue processing loop gets through about 1.12X as many updates).

 

Since the whole VI now takes much longer to complete, i'm guessing that the for loop is waiting for space to become available in the queue before enqueuing the next item?

0 Kudos
Message 8 of 10
(65 Views)

@billko wrote:

@crossrulz wrote:

I think your conclusion on performance is flawed.  You are just seeing how many elements got processed, not how fast the write-read is done.  With a Notifier, if another Notification is sent before that current is read, you lost that data and so it does not get processed.  A queue just adds the data to the FIFO so it can still be processed when that loop gets processor time.  If you change your indicators to to charts and just is the i terminal for the input of the Queue and Notifier, this should become more obvious.


Would testing with a queue length of 1 be a more or less apples to apples comparison?


That did certainly make it more even.  The queue processed ~1.7x elements when I tried that.  It is true that the Notifier has a lot happening behind the scenes (adding timestamps, checking for new element, going through broadcasting code), so I think this is closer to reality as far as "performance" is concerned.  But there other concerns since we are attempting to benchmark things running in parallel, making us dependent on the randomness of how the OS decides to prioritize CPU time.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 10
(63 Views)

@Oldbhoy wrote:

Since the whole VI now takes much longer to complete, i'm guessing that the for loop is waiting for space to become available in the queue before enqueuing the next item?


To better mimic the Notifier, use the Lossy Enqueue Element function.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 10
(60 Views)