lack of resource in the application.

[labmaster]

I am modifying my code developed by a 3rd party company.
The code contains some graphic elements on front panel.
"7" while loops were used in the block diagram to communicate with digital meters and show the progress.
But the loop time is not so fast around  about 200 ms - 1 s.
So, the size of main file is around 3.9 Mbyte.
The computer has the highest specification of intel 9th-CPU and physical enough memory.
While the application is running, 32% of CPU and 240 MB of RAM resource is used normally.

My quesiton is the following.

1) Both the application (.exe file, 32 bit in Win 10) and LabVIEW running shows some lack phenomenon in execution.
   I can feel some lack of resource in windows OS.
   For example, the graphic toggling of some switches shows the delay.
   When the program is stopped by panel close? event, it takes longer time (10 s ~ 1 min) sometimes.
   The operator testified the program is getting slow as time goes on (2 day full operation).
   I checked the profile (memory and performance) in LabVIEW 2018 but I cannot find some special things.
   What kind of stuffs do I need to check to know the reason of this trouble?

2) I can find the file size of main file is getting bigger when I placed large decoration in front panel.
   Is it related to the resource with file size?

3) Do I need to try in 64 bit .exe application?

labmaster.
*) I attached the profile obtained for a short time.

[cbutcher]

1) If you share the VI, we might be able to make suggestions/alterations to improve performance. In general, if you're populating a graph with increasing amounts of data (e.g. over time) then the memory usage will increase, and eventually the display/update/responsiveness becomes sluggish. Decimation or a limited time span of stored data can be suitable solutions for this.

2) VIs include the front panel items in memory. If you open VI Properties (Ctrl+i, or File > VI Properties) then you can select the "Memory Usage" tab and see the memory stored in various parts. Probably this is always fairly small (<5MB etc) unless you're saving large amounts of data (e.g. in graphs) as default values.

3) Unless you're running out of memory (in which case LabVIEW will alert you with an error/dialog box) you probably don't want to switch to 64-bit. If you are running out of memory, then you could a) switch to 64-bit or b) try to reduce the memory used. A) will not improve responsiveness - b) should.

[labmaster]

Maybe, I can find the reason of slow performance.

One of while loop was running fast less than 100 ms.

labmaster.

[stevem181]

The program slowing down over time and the time it takes to shut down indicate fundamental

problems which won't improve by going to 64 bit LabVIEW.

Are controls being polled rather than using an Event Structure?

The program might be running mostly in the UI Thread. Check the
task manager - no CPU Core should be close to 100%

For slowing down - this might be arrays that are unbounded or repeatedly opening references.

Is the block diagram huge? (Just guessing here.)

steve

[billko]

Totally unrelated to the issue, but still relevant:

Make sure you aren't violating any IP agreements by modifying 3rd party code.

[BertMcMahan]

We can't troubleshoot without seeing the VI, but I bet you have a mix of free running (greedy) loops with no timing dependency (leading to massive CPU loads) and some loops with long timeouts in them (likely serial port reads) that make things take forever. That or you're storing up craploads of data, leading to memory issues.