Use of tunnels vs. shift register for queue ID

[JasonWB]

Hi all,

I was recently looking through the TLC Main example found in NI's Intermediate I training class.  There is a producer loop and a consumer loop and in the consumer loop, there is a "Dequeue Element" block which is passed the queue ID from outside the loop via a shift register.  The output shift register is then fed to the "Release Queue" block which releases the queue when the loop is terminated by the end of program.

My question is this - why use a shift register and feed back the same ID to the Dequeue Element every time?  Why not just use a tunnel instead?

Thanks,

Jason

[tbob]

As long as you are using the same queue (not releasing one and starting another within the loop), it doesn't matter if you use a shift register or a tunnel.  The Queue ID remains the same.  I looked at some of my old code and I use a tunnel here.  However, I use a shift register for the Error In and Error Out so that errors get propogated to the next state or loop iteration.

[JasonWB]

Thanks for the quick response!  What you said makes sense.  Although small, do you think there possibly could be a minute performance hit by using the shift register?  Perhaps they require more "maintenance" than the tunnel (I know I am being pick here 🙂

Jason

[Darren]

No overhead that I know of...there's a place in memory allocated for that shift register, just like there's a place allocated for that tunnel.  You're reading from a block of memory associated with the shift register or the tunnel at the start of the loop, and you're writing to a place in memory for the shift register or tunnel when the iteration is done.  I just did some benchmarking of tunnel vs. shift register performance and saw no difference.  As a convention, I pretty much always use shift registers, mainly so I never have to worry about the zero-iteration behavior of tunnels in For Loops, since I've trained myself to always use shift registers when passing data through and out of a loop.

-D

[shoneill]

On the same topic,

When using the same (or even different queues), my loops end up having horizontal stripes all over the place.

What's the real overhead of opening a reference to a named queue each time something is to be written (And closing it immediately after).  This way, the stripes in the diagram disappear and things may get more tidy.  Surely for most applications this should be adequate, or is there a nasty dark side to this idea?

Shane.

[JasonWB]

Well, you're certainly going to have more overhead.  I know what you mean about the stripes - graphical programming has its advantages sometimes, but sometimes it's a pain-in-the-rear - especially when you have a queue reference and error cluster to propogate around.

What I sometimes will do, dependeng on the layout of the wiring diagram, is to just get a reference to a named queue, rather than running the reference around - it saves a lot of wiring and makes it less sloppy!

Jason

[shoneill]

Jason,

"What I sometimes will do, dependeng on the layout of the wiring diagram, is to just get a reference to a named queue, rather than running the reference around - it saves a lot of wiring and makes it less sloppy!"

Er, this is exactly what I meant in my previous post.

I just did some benchmarking and found out that the difference between using an existing reference versus getting and destroying a new reference each time for a named queue is large.  i.e. With a named queue, it takes 7 usec to preview an element using an existing reference and >200us to do it when getting the reference via the queue name each time.

That rules that out then.

Shane.

[tbob]

Sometimes speed is not so important.  When using a state machine, obtaining data from the queue and pushing data onto the queue is a very small part of the overall program.  I can certainly live with a few extra usecs.  I think this is a good idea unless speed is of the utmost importance.  So I wrote a small example in LV7.1 with method comparisons below the main loop.  Have a look at it.

[Darren]

One of the rules mentioned in the LabVIEW Style Guide (that I have also seen mentioned in other style resources) is to *never* use local or global variables as a replacement for wiring.  There are myriad reasons for this rule, including memory usage, speed, race conditions, lack of data flow, and of course, appearance.

I recommend you live with your bent error wires and stick with using wires exclusively in the afore-mentioned example.

-D

[shoneill]

tbob,

I don't have LV 7.1, can you post a pic of the diagram?

I agree that a lot of the time the performance isn't such a problem, but a factor 200 is simply too much to get my principles to ignore.

I don't get the comment re local and global variables...... Maybe the secret lies in tbob's code?

I suppose it would be possible to create a VI similar to a LV2 global to manage opening and closing the queue references and retain the queue name internally to achieve what I was originally talking about.......



Shane.

PS Sorry for the big pic.....

Message Edited by shoneill on 03-23-200609:51 PM