Higher Priority of VI Causes Worse Peformance

[Xiaochang]

I'm testing the influences of the priority setting in LabVIEW.

And I write two VIs. One sends a number to a development board and receives it back every 5ms(the program in the development board is just transmitting whatever it receives), through the serial communication. The other contains 7 while loops and is just written for keeping the CPU at high load. The programs are as picture 1 and picture 2 I attached.

The numbers sent and received in the first VI are values of a sine function. When a number is received, it'll be plotted on a xy graph, and the x position is the actual passed time from the VI starts to this number is received. And if this VI runs alone and normally, the graph will be a sine function.

I start the second VI first, making the CPU at high load, and then start the first VI. When the priority of them is both "normal", the graph plotted in the first VI is almost a normal sine function, as picture 3 shows. And then I set the priority of the second VI to "highest", the graph distorts obviously, shown in picture 4.

These are the same as expected. However, what confuses me is,  when I set the priority of the first VI to "above normal" and "high", the distortion of the graph increases a lot, as well the total time comsumption of the VI. It seems that higher priority of the first VI causes worse performance. The graphs are shown in picture 5 and picture 6 respectivelly.

I test for a few times and get the same results. And I just want to know why this happens.

Thanks so much.

[zou]

Your 2nd VI not only make CPU busy, it also causes thread starvation.

What would happen if you add a 0 ms time delay in each loop?

A time delay puts the thread back to thread pool, so other threads get a chance to run.

[RTSLVU]

I don't think the priority levels work the way you think they work...

Increasing priority levels is not how you increase performance.

Most performance issues and improvements are directly related to your program architecture.  

[altenbach]

I agree with everything that has been said. You have not said what cpu you have, but unless you have 8 real cores (or 16 hyper threaded ones), these loops will compete for limited resources and each will grab an available CPU core for a while while others need to wait. Your other vi is also quite poorly coded. You can eliminate all locals! You are growing an array in a loop, so occasionally the memory manager needs to be called, and data reallocated. Expensive!

And yes, as has been mentioned, a 0ms wait in each greedy loop will be fairer (old example), no specific priority setting needed. (Of course you don't want that in a quick math loop, but any top-level loop is fair game.

I strongly recommend not to mess with priority settings, ever! There are very, very few exceptions.

[Xiaochang]

Thanks a lot.

After adding a 0ms time delay, the figure when the priority is "above normal" and "high" turns much more normal.

However, when the two VIs are both set to "highest" priority, the figure plotted in the first VI distorts again, while it's quite normal when they are both "normal" priority.

Maybe the priority setting just doesn't work as I think.

[Xiaochang]

Hi, thanks for reply.

That's right. How the priority works here really confused me. 

As I replied above, after adding a 0ms wait in each while loop, when the two VIs are both set to "highest" priority, the figure plotted in the first VI distorts, while it's quite normal when they are both "normal" priority.

Maybe I should focus more on the program architecture.

[Xiaochang]

Hi, thanks so much.

Now I think I nearly understand what happens when these two VIs run at the same time(Except how the priority works, that still confuses me. But I might give up thinking about it temporarily).

Also, I'd like to take your advice about the code of my first VI, that really helps me a lot.

I think I'll focus more on optimizing my program instead of messing with the priority afterward.

Thanks again.

[rolfk · Accepted solution]

The priority levels in LabVIEW are not round-robin scheduled. As long as there is even one single VI with a higher priority ready to execute, it will ALWAYS execute and let lower priority VIs starve to dead for CPU resources. As such the priorities in LabVIEW are NOT a feature to distribute the load of an application across multiple VIs. They can be (rarely) useful when you have an occasionally occurring function that you absolutely want to get executed with higher priority than all the rest, but otherwise you simply should leave your fingers from them. They will almost certainly not do what you hope they would do.

They exist in LabVIEW since the earliest days of LabVIEW (when LabVIEW itself was only running on cooperative OSes, rather than true multitasking/mulitthreading OSes) and there they could sometimes help to make certain things work more reliably, But nowadays these priorities are a relict from the pre-stone age of LabVIEW, which only have not been removed yet because that costs time and effort and has the potential to break other code in LabVIEW in very unexpected ways.

[Xiaochang]

Thanks a lot for the explanation! What I'm confused about is just answered. And I won't change the priority setting anymore unless necessary.

[billko]

---

@Xiaochang wrote:

Thanks a lot for the explanation! What I'm confused about is just answered. And I won't change the priority setting anymore unless necessary.

---

Let's all just emphasize that "unless necessary" doesn't really mean anything because "necessary" happens so rarely that you wouldn't even recognize it when it happens.  That is literally the last thing I would consider if my application were having performance issues.  It should be yours, as well.