Optimizing loopp performance

[rpodsim]

Howdy!

I've been working with labview for about 2 years now and the current project I'm working on requires that I optimize a control loop to the extreme. We're trying to squeck out the most perforance possible.

My question primarily deals with queues, notifers and RT FIFO's and Default values.

Which of the follow would be have a better execution time or perhaps you could reccommend another procedure.

A:

B:

I realize that those are rather simplistic examples but I'm' trying to squezze out every ounce of performance I can.

Just as a reference I working on a PXI 8145 RT system.

Thank you for suggestions:

Ryan

[Eugen Graf]

I don`t understand why you do not connect the data from Enqueue to the loop termination terminal. And I think to use "0"-timeout is not really good. I preffer "-1" as timeout value.

[Mellroth]

QUOTE (rpodsim @ Apr 9 2008, 10:14 PM)

Which of the follow would be have a better execution time or perhaps you could reccommend another procedure.

I would suggest that you actually benchmark the code (run the code N times and check duration) to see which piece of code is faster, but I guess you are looking for general remarks.

First, I don't understand what you are getting at with these screen shots, the only difference as far as I can see (before my first cup of coffee) is that you have wired the default values in B? Are you actually asking whether or not to wire default values to all inputs? There is another thread here on LAVA that discusses the benefits of wiring all inputs to a sub VI call, check that thread to see if that might help.

Second, in the lower part of the RT FIFO init, you can select mode of operation, polling or blocking for both read and write operations. Polling, which is default, is faster as long as you have the CPU power, on lower end machines (e.g. cRIO) the blocking can actually be faster. ryan

QUOTE (Eugen Graf @ Apr 9 2008, 11:10 PM)

...And I think to use "0"-timeout is not really good. I preffer "-1" as timeout value...

Most times I would agree with you, but in this case where Ryan is trying to minimize overhead using RT FIFOs, timeout 0 is OK (and preferable).

The reason is that with timeout = 0, the read operations just polls the buffer instead of waiting for an event.

/J

[Rolf Kalbermatter]

QUOTE (JFM @ Apr 10 2008, 01:00 AM)

Most times I would agree with you, but in this case where Ryan is trying to minimize overhead using RT FIFOs, timeout 0 is OK (and preferable).

The reason is that with timeout = 0, the read operations just polls the buffer instead of waiting for an event.

But it does do so very fast then without any other means of throttling the loop iteration. I'm sure that waiting on an event of data being available would be a lot more performant than checking the contents of the queue many 100 or even 1000 times a second.

But if your system hasn't to do anything else this would be a moot point.

Rolf Kalbermatter

[Mellroth]

QUOTE (rolfk @ Apr 10 2008, 08:22 AM)

But it does do so very fast then without any other means of throttling the loop iteration...

Throttling does not seem to be the goal here, but to run each iteration as fast as possible (a calculation loop maybe?).

If the loop would only perform an action when the RT FIFO was set, then I would also go for the event, but in this case the RT FIFO is used to check a STOP condition.

/J

[Rolf Kalbermatter]

QUOTE (JFM @ Apr 10 2008, 03:33 AM)

Throttling does not seem to be the goal here, but to run each iteration as fast as possible (a calculation loop maybe?).

If the loop would only perform an action when the RT FIFO was set, then I would also go for the event, but in this case the RT FIFO is used to check a STOP condition.

Yes but what else will be going on in this loop? In the way as in the example without anything else this loop will really put a heavy load on the CPU for nothing. If there is something else going on in that loop that needs to execute as often as possible then yes I would agree that the 0 timout is a good idea, but not because it will offload the CPU in any way by not using events internally but simply because you do not want the loop iteration interval to be limited by the Deque FIFO node.

Rolf Kalbermatter

[rpodsim]

Thank for the Responses guys. After Rereading the my post I realize I didn't do the best job at explaining the goal.

My questions has to do with wiring the default values of subvis (Mainly RT FIFOs). The loop I trying to optimise is a machine control loop with with several different RT FIFOs, data IO and Calculations. Several of the FIFOs deal with control parameters that 90% of the time don't change. (Hence the 0 timeout.) The loop timing is controlled by a timedloop structure. The goal is to reach 5kHz, I'm currently at about 4.75kHz. Hence the reason I'm looking everwhere I can. That being said..

I did a Timing test as you suggested JFM and came up with something I can't figure out. I ran three different cases:

Case 1:

RT FIFO with only the required inputs wired

Case 2:

RT FIFO with all but the error inputs wired

Case 3:

RT FIFO with all inputs wired

I ran the test with 200000 iterations per Case

What found was that Case 1 turned out the be the fastest. Followed by Case 2 though only marginally. Case 3 was the one that interested me. By wiring a constant to the error input of the RT Read function the run time increased by ~50%.

I had read somewhere that a performance difference exists between required and recommended vi inputs, but since I can't change the RT FIFO inputs I thought that wiring values to the inputs would inprove the performance but that doesn't appear to be the case. I'm hoping maybe someone here might have an idea why. I disabled auto error reporting and debugging and was running in a PXI RT Target, though that didn't change the relationships between each test. I have included the vi I was using to the perform the test.

Oh, I must be search challanged, as I am unable to find the post you are refering to JFM. I did find a link to the NI performance and memory management document, which helps in a few different areas.

Thanks,

Ryan

Oh the Vi is 8.5. I don't have any earlier versions of labview available.

Edit: Added screenshot of VI