Large LV application slows computer

[battler.]

Hi guys,

Large LV application consists of main state-machine containing sub-panel. 

Main app first runs 4 (also large) independent sub-processors (VIs) in background and allows user to switch/toggle between and view their respective front panels in sub-panel of main app.

The sub-processors wait for ever for user input to perform calculations.

Information is passed between sub-processors using functional globals.

The sub-processor VIs contain numerous subVIs with high execution priority or are subroutines.  This is because I found that the millions of calculations are performed faster at these priorities.

Problem:

I find when I start this application that the PC it runs on is highly stressed; the fan starts on a laptop gets hot.

It is definately running inefficiently.

It's not a particularly large program (about 40 MB on disk).  Overall about 1000 VIs.

What areas of the program should I be looking at to fix this issue?

[uChiron]

It's hard to say something without seeing the code,but here some tips:

Search "Coercions Dot" in functions (red annoying small dot in terminals) around the code, work with small datatypes (U8,U16...), avoid resizing array constantly (Preallocate if u know the final size), use Dynamic VIs, avoid complex datastructures like a clusters,array of clusters,cluster in another cluster with 2D array...;,use "In Place Structure" where LabVIEW create a memory buffer (easy to find using Show Buffer Allocations window),use Reentrant VIs wisely,break ur code in SubVIs, use paralelizable for loops,use queue/notifier in ur code, use shift register when working with bunch of data in a loop....and so on.

NI webpage have LOT of whitepapers/webcasts talking about this. U can search and read/see 😄

[Himanshu_Goyal]

Dear Battler,

Use Execution Trace Tool Kit.

This trace tool kit will tell you the code or VI that are consuming the memory of your PC.

[altenbach]

---

@battler. wrote:

The sub-processor VIs contain numerous subVIs with high execution priority or are subroutines.  This is because I found that the millions of calculations are performed faster at these priorities.

---

How did you benchmark this? How much faster (10% faster, orders of magnitude faster)?

What you are doing  here might be a very misguided approach. You should disable debugging, but set these priorities back to normal. Maybe inline some often-called inner subVIs instead.

From the help:

"However, subroutine priority VIs block the execution of other VIs on the same thread until the subroutine priority VIs finish execution."

Also note that high execution priorities starve the UI thread and the VI this becomes very slugging to operate or update the front panel.

Have you done any profiling? Can you identify wich subVIs use most of the CPU?

[battler.]

Running as subroutine is many times faster.  These are number crunching routines working on large arrays.

What is the point of have the subroutine priority if it shouldn't be used.

In most cases either the number crunching routines are in separate processing loops or the user needs to wait for the results anyway.

The issue is even when no calculations are being performed and the application is idle it obviously uses vasts amounts of memory as the PC is straining (note processor % is still low).  Hope this makes sense..

[Norbert_B]

Hm, i think you go down a dangerous road of argumentation.

---

@battler. wrote:
[..]What is the point of have the subroutine priority if it shouldn't be used.[..]

---

Then one can ask: Why shouldn't an intelligence agency NOT use certain technologies if they are available?

OK, OK, this is a bad discussion, so please don't go into it, but.... there are technologies (also in LV) which are NOT recommended due to several reasons. Subroutine priority is one of them.

You CAN use it, if you know exactly what you are doing to your system with it.

And reading your questions regarding "power consuption of the computer and unexpected behavior", i am not sure if you really understand the underlaying technology.

Besides, i am NOT convinced that your LV application is the one and only reason for the computer to react "odd".

Are you sure that the computer does not run updates, do some harddrive indexing, scanning for virus, ... in the background?

just my 5 cents,

Norbert

[battler.]

---

@Norbert_B wrote:
 

there are technologies (also in LV) which are NOT recommended due to several reasons. Subroutine priority is one of them.

You CAN use it, if you know exactly what you are doing to your system with it.

---

Could you please mention the "several reasons" if you know.  I have read the LV documentation but require more insight.  There was a reason why I mentioned the subroutine execution priority in the first place..

The same issue of high computional intensity at idle (immediately following start-up) has been mentioned to us by several customers.  It is not just on my computer and the strain is more obvious on a laptop.

Any tips and guidance to solve are appreciated.  Note I am aware of the basic optimisation tips already mentioned.

I plan to do some analysis although I am not experienced at using the LV VI Analysis tools on large applications.

Does having (loading) 4 large independent state machines running (and awaiting command) at once in the background cause this sort of memory burden at idle?

[Norbert_B]

VI Analyzer might give some useful tips, but the main tool to track performance issues is the Desktop Execution Trace toolkit.

The main disadvantage of SUBROUTINE as priority level is already stated in altenbach's reply in this post.

But i feel that you (and you are not alone by this) don't really understand the underlaying results of it.

---

@altenbach wrote:

What you are doing  here might be a very misguided approach. You should disable debugging, but set these priorities back to normal. Maybe inline some often-called inner subVIs instead.

From the help:

"However, subroutine priority VIs block the execution of other VIs on the same thread until the subroutine priority VIs finish execution."

---

What does that imply?

1. You can starve parts of your application

2. You create 100% CPU load on a single core except you have static waiting times (still the thread blocks the core)

3. The complete content of the subroutine subvi is serialized in a single thread. There is no parallelism in this subvi anymore.

4. Waiting on other threads (queues, notifier, ...) can lead to dead-lock comparable situations (still not freeing the core for other stuff)

There could be even more issues created by setting subvis to subroutine.
Also, if you set a VI to subroutine, you commit to MAXIMUM power draw for execution of this VI for the CPU (as there are usually no waiting times). So you pay improved runtime speed with increased power consumption and less responsiveness of the complete system.

If no subroutine VI is executed, and you included enough "free time" (e.g. waiting on events), power consumption should go down to a reasonable value. True.

But have you ever checked for "idle consumption" if running an "empty" application?

Have you ever compared this to other, non-LV based applications like office, IE, ....?

Also, make sure that things are not running in parallel to your application. I already mentioned some typical services which increase power consumption (greatly) from time to time; and most Windows based systems run those so i am not surprised that other systems also show this behavior.....

Norbert

[battler.]

Thanks Norbert that helps.  I am looking into the Desktop Execution Trace toolkit.  I hope it's part of the Developer Suite.

You mentioned important drawbacks of the subroutine priority and I witnessed some of these during extensive experimentation.  In the end I decided it was better to sacrifice some responsiveness and to wait 5 min instead of 10 min for a calculation.  Are there any positive points and recommended situations to use them?

However, I can accept the computational burden during the actual calculation but not during idle when only in memory.

May seen like a silly question however I have reasons to and must ask:

Does having a large VI in memory which contain several subVIs at either high-prioirity or subroutines (at idle) create a less responsive environment?

[Norbert_B]

Yes, the DETT is part of the DevSuite (just as the VI Analyzer).

In my experience, the net gain of setting a subvi to SUBROUTINE priority often is neglectable compared to the backdraws you have connected to this setting.

Nevertheless, there are of course situations where this setting is desirable. Recommendation is that the setting is used for VIs running very short, but being called quite often. These functions are very important and everything else might be starving for this.

As altenbach already pointed out as well, checking "inlining" could reveal a bigger performance gain then setting priority to SUBROUTINE.

I suggest you post one of the VIs you are now running as subroutine. We probably can give you some additional hints to improve the code performance-wise so the setting is not necessary anymore.

Also altenbach told you to disable debugging for the VIs. This is a valuable hint as the compiler can perform better optimizations on the code (e.g. "constant folding" of structures) which are disabled when the VI is debuggable.

Subroutine automatically disables debugging, so maybe this is already one of the key points for the performance gain.

---

@battler. wrote:
[..]Does having a large VI in memory which contain several subVIs at either high-prioirity or subroutines (at idle) create a less responsive environment?

---

What do you refer to with the term "environment"? RTE or the LV Dev Environment?

Having a high priority subvi which is not executing has no negative effect on the overall performance. So there shouldn't be that much effect in the first place.

This has some limits as system resources are limited (number of threads per application, swapping threads, .....) so it *could* effect responsiveness, but it is unlikely as long as those subvis don't execute.

Norbert