Increasing occupation of the PC RAM of executable with RunTimeEngine

[scmm]

Dear Community,

thanks in advance to those who will answer!

My problem is: I've a MAIN.vi, basically consists of a Simple State Machine (SSM), that once compiled and executed with Run Time engine uses PC RAM quantities increasing and finally hang up.

This behaviour is not present when I execute the VI in LabView.

In fact if I I monitor the PC resources with "Task Manager" during execution with RunTimeEngine I see RAM occupation grow up.

On the contrary when I monitor the execution in LV with Tools>>Profile>>Performance and Memory... and contemporary monitor the PC resources with "Task Manager" I see the RAM occupation constant.

Can you help me to find a way to understand who is the "RAM eater" in my application with RunTimeEngine?

Reading some questions about the memory usage I understand that type structures like "build array" and "concatenate string" are deprecated.

I undrestand how to replace the structure "build array" with more efficient one but I don' know how to replace the concatenate string. Both the structure are largely used in my application...unfortunately

I attach a very very simplified example of my application in order to show you what I think are some of my mistakes!

I use LabView 2014 SP1 and Windows 7 Professional SP1 (64bit)

Thank you so much

monica

[crossrulz]

Way too many uses of property nodes.  Use the actual terminals whenever possible.  And use the Latching capabilities of the buttons so that you do not have the reset their values yourself.

These are not likely causing your memory growth, but they are an issue.

[scmm]

Thank you very much crossrulz,

What I don't understand is the double behaviour in RunTimeEngine and LabView.

What kind of structure can have such a different behavior in the two environments?
Especially what may be the instruments of investigation apart from the Task Manager of windows?
Surely there is a mine programming error but at the moment it is like looking for a needle in a haystack because my .vi has a lot of subVi and a lot of "interactions".

However I will treasure your suggestion and I will start from that

thanks

[billko]

Actually "lots of subVIs" makes it easier to debug, not more difficult.  It breaks that huge old haystack into several smaller ones.  It gives you a means of easily focusing your debugging energy on small pieces of code and you are far more likely to find the issue as a result.

[stockson]

Actually "lots of subVIs" makes it easier to debug, not more difficult.  It breaks that huge old haystack into several smaller ones.  It gives you a means of easily focusing your debugging energy on small pieces of code and you are far more likely to find the issue as a result.

https://en.wikipedia.org/wiki/Cohesion_(computer_science)

https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

🙂

[Ben]

I can not recall a situation where the exe ate memory and the development did not.

Are you SURE you ran the application as long and under the same conditions as the exe?

Are you ABSOLUTELY sure?

Start with the VI Anaylzer to looking for obvious issues and fix them.

if that fails and you are sure there are no memory consumption issues in the development environment (note sometimes the memory consumption in the development envirnment will only show up after a good long run sinc ethe growth may be small and burried in the memory used for development, un-do buffers etc) then stick with the Windows Taks Manager to track the rate of memory usafe. If it grows in the development environment, use the Profile VIs >>> Memory to narrow down the culprit.

If you are still not making progress you can start wacking away pasrts of the application and trying to narrow it down to the offended sub-system. If possilbe, toss half of the application, and test it extensively.

Take care, have fun, report what you learn please.

Ben

[natasftw]

Where have you seen anything referencing build array or concatenate string as deprecated?

You ask how the two perform differently.  I'd have to look at your exact code to give any guidance about your situation.  But, often tests are ran differently depending on the environment.  Are you letting the development code run for the same duration?  Is it performing everything exactly the same or are you running test cases?  Does the data get as large in development?

[scmm]

Thanks to everybody for the answers and the suggestions.

The indication of non-use build arrays or concatenate string I got from the Italian NI technical support contacted for the same reason why I turned to the community.

The reason they told me is that build arrays and concatenate string allocate memory dynamically and this can give problems in RunTimeEngine rather than in the development environment.

The technical support was very very kind and I shared with them my code but they said they cannot go into the details of the code, they can only give general guidelines so I didn't solve my problem

Your considerations lead me to do more extensive testing, and of course to share with you the results

thanks!

[thoult]

Whenever I have a worry about memory or reference leaks, I immediately think of using the Desktop Execution Trace Toolkit.

To be honest, I use it even when I don't have any concerns - it's usually part of my testing before releasing anything. I recognise not everyone wants to spend the money on it, but as a VLA user using the Professional Development System, this is included in my package.

[scmm]

Hello everyone, I started my tests and I wanted to share with you the first results.
Exactly the same conditions I ran my Main.vi while I monitored the memory usage in Windows Task Manager; first time in LabView and then in RunTimeEngine.
My .vi is a state machine that remains in" Idle"until you press the start button, then it executes all cases and then returns to "idle".
I run six rep and I notice that in LabView memory is allocated and then deallocated in a run with respect to that other; in RunTimeEngine the memory is only allocated.
My first modify was to replace "redundant" property node as suggested by "crossrulz" and my first result was very good in terms of absolute value of memory usage.
I have summarized my first results in the following image.
Than I start working with "Desktop Execution Trace Toolkit." that was really a revelation! (thanks thoult)
I am learning to use the tool, but I've already found several "reference leaks".
I continue in my work hoping to soon find my mistake and share it with you
thank you all