Dequeue element overhead

[probably]

When the Dequeue Element function is used, as in the framework "Producer/Consumer Design Pattern (Events)", how often does the function poll the queue?

Does this represent a significant overhead?

[falkpl]

You can specify how often: -1 will wait indefinitely until the queue has an element.  This mode is usually used for a producer consumer since the consumer will wait for something to consume but you can also specify in ms how often to poll the queue for a dequeuing event, and 0 is as fast as possible.  As for overhead, I have never have noticed significant overhead since the consumer loop usually has code which will dominate any overhead of the dequeuing call.

Paul

[probably]

Thanks for the reply, but I don't quite understand that.

Surely the timeout and the polling rate are independent? For example, if I set the timeout for 50ms or 100ms, how do I know how often the Dequeue Element Vi is checking the queue?

[shoneill]

You're mixing things up a little.

The timeout is the amount of time the function waits for before moving on if no Item is present to dequeue within that time.  If an object becomes available to dequeue, it will be dequeued and the function will end earlier.

The function does not "poll" the queue.  It works on an interrupt basis, meaning it's pretty efficient in regards to CPU time it requires.  The Queue will be checked out pseudo-instantly, while still not hogging CPU resources.  Cool eh?

At least that's my understanding of it.

Shane.

[Sheldon_Stokes]

I would guess that the overhead for queueing and de-queueing is the same as adding or deleting an element to an array (IE changing it's size: think mutable).  You wouldn't want to design a queue data structure as a fixed size array due to wasted memory or large queue size issues.  So I'd guess that the queue data structure actually grows and shrinks in memory as elements are added or removed. 

Sheldon

[shoneill]

Actually, I disagree.

I also see no reason for a Queue to require a contiguous memory space to store many elements.  Ever heard of linked lists?

If it really is similar to arrays, then the act of adding to the beginning of a Queue must be significantly less efficient than adding at the end.  Anyone got a benchmark to test this?

During the last few months people have been posting about how surprisingly efficient and fast passing data via Queues is.  I would say that the overhead required to queue or dequeue is negligible.

Of course, if you're queuing a 1MB array every millisecond or so it'll be a different story, but for "normal" use, it's easily fast enough.

Shane.

Message Edited by shoneill on 09-30-2005 12:28 AM

[probably]

That helps; I don't know anything about "interrupts" in terms of how the function becomes "aware" when a queue elements is added. Do you have pointers (no puns...) as to how this works, or is this standard stuff I have not come across before?

[falkpl]

If you are really worried about overhead you can profile the vi in action and see how much time is spent on average on the queuing and dequeuing event.  This will probably depend on the data structure used since the queue can assume any type in labview.  My experience has been the the overhead for the queues is minimal and well worth the ease of use.  Sorry polling is not the correct term, it is interrupt based but you can control the frequency of the interrupt in ms or wait for a queue event to wake up the tread waiting on the dequeuing. 

Paul