Effects of Bundling Queues?

[jrveale]

Hi All,

I have a project that includes multiple parallel loops which are controlled via a number of queues by an event handling loop. The parallel loops may also enqueue items to each others' queues. Everything seems to be working fine, but the mess of wires bringing a number of queues into each loop is ugly, and leaves me prone to wiring errors.

To avoid this, I'm considering bundling the queues' wires together and feeding the bundle into each loop, the loops can then unbundle the queues they need, when they need them.

I'm a little worried that this may have unexpected effects on the data flow. I don't think it should be a problem as the queue wires are refnums. So while the queues themselves are changing, the refnums aren't, and all should be fine?

I'm also wondering if a significant performance hit is to be expected from potentially performing multiple unbundles in every iteration of every loop - the project isn't particularly processor hungry / constrained, but I think it's worth considering.

I'd appreciate any feedback on this.

[billko]

As far as I can see, only good things can happen.  😉

[crossrulz · Accepted solution]

I don't see anything inherently wrong with what you described.  Unbundling will have very very little impact on your performance.  You will have much bigger things to look at if performance becomes an issue.

[billko]

There are other things you can consider, also.  Using normal globals to contain the queue refs, or in an action engine to perform queue operations as well as having all the refs in one convenient location works, too.  (You might want to take advantage of this Google Search to learn about some potential pitfalls of the A/E method.  I know this is actually a search on "functional globals" but there were surprisingly very few hits for Action Engines.)

[jrveale]

Thanks all, seems to be working well & my block diagram is tidier than ever

[Bob_Schor]

If you do build an Action Engine to manage a Queue (a technique I've used that I dub the "Wireless Queue", as the Queue "wire" lives on a Shift Register inside the Action Engine, and when first called, creates the Queue), be sure to not include "Dequeue" as one of your Actions (as it will cause the AE to "block" waiting for something to be put on the Queue, so it can't enqueue ... a very obvious Stupid Thing to Do which I, of course, stupidly did!).

With a Wireless Queue, you don't need to name any of the Queues (as you'll reference them by calling the AE).  You won't have Queue wires anywhere (except the AE will have the Queue as its upper-right output Indicator so you can wire it to the Dequeue Element when you need it), which makes your Block Diagram a little neater.  Be sure to create an Obvious Icon for the AE that names the Queue it contains.  So now you don't need to Cluster, you just call the AE for the Queue you want (I was going to say "and Bob's Your Uncle", but I'm probably not ...).

Bob Schor

[billko]

---

@Bob_Schor wrote:

If you do build an Action Engine to manage a Queue (a technique I've used that I dub the "Wireless Queue", as the Queue "wire" lives on a Shift Register inside the Action Engine, and when first called, creates the Queue), be sure to not include "Dequeue" as one of your Actions (as it will cause the AE to "block" waiting for something to be put on the Queue, so it can't enqueue ... a very obvious Stupid Thing to Do which I, of course, stupidly did!).

With a Wireless Queue, you don't need to name any of the Queues (as you'll reference them by calling the AE).  You won't have Queue wires anywhere (except the AE will have the Queue as its upper-right output Indicator so you can wire it to the Dequeue Element when you need it), which makes your Block Diagram a little neater.  Be sure to create an Obvious Icon for the AE that names the Queue it contains.  So now you don't need to Cluster, you just call the AE for the Queue you want (I was going to say "and Bob's Your Uncle", but I'm probably not ...).

Bob Schor

---

Spoil-sport.  😉

[Bob_Schor]

As one of my twins would say, "Ha, ha, ha ..."  Now that you've really highlighted the caveat, there's No Excuse for "doing a Bob" ...

BS

[billko]

---

@Bob_Schor wrote:

As one of my twins would say, "Ha, ha, ha ..."  Now that you've really highlighted the caveat, there's No Excuse for "doing a Bob" ...

BS

---

Unfortunately, this was a voyage of self-discovery for me, too.

[natasftw]

---

wrote:

I don't see anything inherently wrong with what you described.  Unbundling will have very very little impact on your performance.  You will have much bigger things to look at if performance becomes an issue.

---

I'd be pretty surprised if the compiler didn't just optimize this out.  The value will never change once the application starts and creates the reference.  I'd guess it is smart enough to see this and just access the reference each time without going to unbundle to get the reference.

But, if it doesn't, it's a minimal thing.

Adding the bundles (especially using by name) allows for easier to read code.  You can unbundle the name to self document your code as you go.