Queue performance

[Gary Rubin]

I'm sure I've read something related to this, but struck out using the lavag search. I apologize if this is a rehash of something that's already been covered.

We have an application in LabVIEW 7.1 in which we're using queues to pass data between parallel loops. Because there are memory allocations associated with enqueueing (and presumably deallocations for flushing?), would it be better from a performance standpoint to use an LV2 Global containing a preallocated array?

Also, I seem to recall that there had been some improvement in how queues are implemented in LabVIEW 8.x. I've been trying to get us to upgrade, but nobody seems to want to spend the $$. Are there queue (or other) performance issues that I might be able to point to?

Thanks,

Gary

[jdunham]

QUOTE (Gary Rubin @ Mar 20 2009, 08:59 AM)

We have an application in LabVIEW 7.1 in which we're using queues to pass data between parallel loops. Because there are memory allocations associated with enqueueing (and presumably deallocations for flushing?), would it be better from a performance standpoint to use an LV2 Global containing a preallocated array?

I don't see why the use of queues would add much memory allocation. If you pass a string to a queue, I don't think the string would need to be copied. Now the original wire probably requires a buffer allocation, because you might run the diagram again and get a new string, and the old string still exists in the queue, so LV will have to make a new string for the wire. But the same thing will happen if you pass your string to some other thread by any means, including a queue or an LV2 global.

In LV8, there is a shipping example that has a 'singleton' pattern, which you can use to ensure that only one copy of an object ever exists, and if correctly used, should never require a memory copy. That pattern is implemented with queues.

So is there a performance problem? You probably shouldn't be worrying about performance unless there is a real problem.

QUOTE (Gary Rubin)

Also, I seem to recall that there had been some improvement in how queues are implemented in LabVIEW 8.x. I've been trying to get us to upgrade, but nobody seems to want to spend the $. Are there queue (or other) performance issues that I might be able to point to?

Well LabVIEW 7.x is at least 5 years old. I think there have been a lot of improvements, including the queues (though I thought they got their face-lift after 6.x), and of course libraries, lvclasses (LVOOP), Xcontrols, I can't remember what else. If you want to keep your LabVIEW chops up professionally, it's not good to ignore all of the new stuff.

One thing that has changed is that LV 8 has real licensing and a yearly maintenance cost, which is optional, but then you don't always get the bug fix upgrades. If your company steals LabVIEW (violates the license agreement), and you upgrade, it will probably be harder to keep doing so, and more money will be spent per year. Now the cost of LabVIEW is a few thousand dollars, which is just a couple percent of the yearly cost of employing an engineer in the US. It's hard to have sympathy for a company that doesn't want to spend an appropriate amount of money on LabVIEW. You'll have to forgive me if I made assumptions about the situation at your workplace, I realize I may be off-base, and there could be real reasons for not wanting to spend money to keep the tools current.

[Grampa_of_Oliva_n_Eden]

QUOTE (Gary Rubin @ Mar 20 2009, 11:59 AM)

I'm sure I've read something related to this, but struck out using the lavag search. I apologize if this is a rehash of something that's already been covered.

We have an application in LabVIEW 7.1 in which we're using queues to pass data between parallel loops. Because there are memory allocations associated with enqueueing (and presumably deallocations for flushing?), would it be better from a performance standpoint to use an LV2 Global containing a preallocated array?

Also, I seem to recall that there had been some improvement in how queues are implemented in LabVIEW 8.x. I've been trying to get us to upgrade, but nobody seems to want to spend the $$. Are there queue (or other) performance issues that I might be able to point to?

Thanks,

Gary

Hi Gary,

The big performance related change is the "memory Control" palette that iclude the operators to explicitly tell LV to work "in-place".

Check NI web-site for the release notes for all of the intermediate version for something that you think would be a good selling point.

As far as development goes the Quick Drop functions added with LV 8.6 are absolutly adicting once you have your short cuts defined and memorized ! I can drop any my 53 most frequently used operators in the blink of an eye and even a confernce room full of LV Architects were impressed when I demoed the short-cuts for the rest of my group.

Ben

[Mark Yedinak]

I have never encountered any performance issues when using queues. Also, NI has done a good job of optimizing them. One nice feature in 8.6 is the ability to have a circular queue. That is, if you define a maximum size old elements are dropped once you reach the size limit and the new element is added. Prior to 8.6 if you wanted to do this you had to have wrappers around your enqueue to manually do this.

Also, I agree that it is worth getting the maintenance agreement. The cost is negligible when you compare it to the benefit.

[Gary Rubin]

QUOTE (jdunham @ Mar 20 2009, 01:43 PM)

I don't see why the use of queues would add much memory allocation.

That assumption was based on the following from the Obtain Queue help:

Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Therefore, resizable data types such as paths, strings, arrays, and so on can still increase and decrease the overall queue size

QUOTE (jdunham @ Mar 20 2009, 01:43 PM)

So is there a performance problem? You probably shouldn't be worrying about performance unless there is a real problem.

This is a system that has to keep up with real-time data flow. The faster the code is, the higher a data rate it can keep up with. There's always need for more performance.

QUOTE (jdunham @ Mar 20 2009, 01:43 PM)

Now the cost of LabVIEW is a few thousand dollars, which is just a couple percent of the yearly cost of employing an engineer in the US. It's hard to have sympathy for a company that doesn't want to spend an appropriate amount of money on LabVIEW. You'll have to forgive me if I made assumptions about the situation at your workplace, I realize I may be off-base, and there could be real reasons for not wanting to spend money to keep the tools current.

This is a project that's been going on for the past 6 years or so. It is in LV7.1.1 because that was the latest and greatest when we started (we might have even transitioned the project from 6, I don't remember). There has been a lot of time spent on code development and fine-tuning, and everyone is finally pretty convinced that it's doing what it's supposed to. Our prime doesn't understand why they should have to fork over several additional $k just for the latest version of the development environment when it won't change the code, operation, or anything else a user might care about. Furthermore, the end-user customer might want to be re-convinced that everything still works after the configuration change (i.e. upgrade from 7.1.1 to 8.6). That is both a time-consuming and expensive endeavor.

[jdunham]

QUOTE (Gary Rubin @ Mar 20 2009, 10:19 AM)

That assumption was based on the following from the Obtain Queue help:

Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Therefore, resizable data types such as paths, strings, arrays, and so on can still increase and decrease the overall queue size

Sure, but if your queue size is not changing (why would it change if you are using it like a functional global) then there should be no reallocation. In general the queues have great performance, but I don't know whether 8.x brought any performance improvement.

QUOTE (Gary Rubin)

This is a project that's been going on for the past 6 years or so. It is in LV7.1.1 because...

All those points are reasonable. But are you still using 6-year-old computers? If it's OK to keep up-to-date with hardware, why shouldn't the same be done with software? A well-run project should take into account that regular upgrades of hardware and software are part of the development process.

It's also better risk management to have a process for upgrading on a reasonable basis that to wait until it's absolutely necessary and upgrade a system that has never changed before because there is some showstopper issue. I think you can find real reasons to upgrade, and good luck with the selling that to the managers and customers.

[Gary Rubin]

QUOTE (jdunham @ Mar 20 2009, 02:39 PM)

Sure, but if your queue size is not changing (why would it change if you are using it like a functional global) then there should be no reallocation. In general the queues have great performance, but I don't know whether 8.x brought any performance improvement.

Queue size changes because the rate at which data is coming in is not constant, and we don't have the luxury of waiting until a queue (buffer) reaches a certain size.

[Gary Rubin]

QUOTE (Gary Rubin @ Mar 20 2009, 12:59 PM)

would it be better from a performance standpoint to use an LV2 Global containing a preallocated array?

Some benchmarking showed that queues were faster.

QUOTE (Gary Rubin @ Mar 20 2009, 12:59 PM)

Are there queue (or other) performance issues that I might be able to point to?

Thanks to those who provided some "ammunition".

[Aristos Queue]

QUOTE (Gary Rubin @ Mar 20 2009, 12:19 PM)

That assumption was based on the following from the Obtain Queue help:

Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Therefore, resizable data types such as paths, strings, arrays, and so on can still increase and decrease the overall queue size

Grrr... A bug report against the documentation will be filed shortly. That should read:

QUOTE

max queue size

only limits the number of elements in the queue. It does not preallocate that many elements in the queue. If you want to preallocate your queue, enqueue that many elements and then flush the queue. The space, once allocated, will remain allocated for further use of the queue.

Enqueueing and dequeueing resizable data types, such as paths, strings and arrays, do not affect the memory of queues. The queues are used to move data around, but they do not generate copies of the data.

[bsvingen]

QUOTE

max queue size only limits the number of elements in the queue. It does not preallocate that many elements in the queue. If you want to preallocate your queue, enqueue that many elements and then flush the queue. The space, once allocated, will remain allocated for further use of the queue.

Enqueueing and dequeueing resizable data types, such as paths, strings and arrays, do not affect the memory of queues. The queues are used to move data around, but they do not generate copies of the data.

How about a random access queue?

[Aristos Queue]

QUOTE (bsvingen @ Mar 21 2009, 01:25 AM)

How about a random access queue?

We call that an array.

QUOTE (Aristos Queue @ Mar 20 2009, 04:15 PM)

Grrr... A bug report against the documentation will be filed shortly. That

should

read:

It appears this documentation was already changed in LV8.6. You must've been quoting an earlier version of the Obtain Queue documentation. In any case, it was wrong no matter which version of LV you were using Obtain Queue.

[Gary Rubin]

QUOTE (Aristos Queue @ Mar 20 2009, 06:15 PM)

Grrr... A bug report against the documentation will be filed shortly. That should read:

That was LV7.1.