The cycle time of the application is increasing

[BaSs_Garrido]

The average time is 0.045 sec. approx. but after the application executes several cycles and the time increases to 1.5 seconds.
You need to restart the app to reset the time.

Any method to avoid this, I understand that it is something that accumulates memory or something like that but I don't know how to clean everything like when the application opens

Note: running the VI as .exe from windows

[paul_a_cardinale]

In order to figure out what might be wrong, I tried looking at your code.  But I didn't see anything.

[altenbach]

---

@BaSs_Garrido wrote:

The average time is 0.045 sec. approx. but after the application executes several cycles and the time increases to 1.5 seconds.
You need to restart the app to reset the time.

Any method to avoid this, I understand that it is something that accumulates memory or something like that but I don't know how to clean everything like when the application opens

Note: running the VI as .exe from windows

---

• So why would you show us a picture where the times are not increasing???
• Does it just go to 1.5s in one step and stay there, or does it continue to increase?
• How do you measure cycle time?
• What does the cycle do? What is the time limiting step?
• What does the windows task manager say about CPU and memory use over time?
• Are you resizing array in loops (growing, shrinking).
• Do you have uninitialized shift registers?
• Is all code pure LabVIEW or are there third party drivers and DLLs, etc.
• Who wrote the program? How big is the diagram?
• Does the same happen if you run it in the development environment? (Since you say "as exe", it seems relevant)

Once we see your VI, we can probably point to the problem areas quickly.

[wiebe@CARYA]

---

@BaSs_Garrido wrote:

Any method to avoid this, I understand that it is something that accumulates memory or something like that but I don't know how to clean everything like when the application opens

---

There are quite a few things that can leak memory (probably incomplete):

By value containers (strings, arrays, maps, sets);
References (LabVIEW, .NET, AX);

Dynamic\external memory (CLFN);

By reference containers (queues, notifiers);

Channel Wires;

Events;

All the mentioned data elements can leak when put into shift registers, feedback nodes, and\or with locals and\or their value property.

The other mentioned items can leak on their own.

[altenbach]

---

wiebe@CARYA wrote:
There are quite a few things that can leak memory (probably incomplete):

---

... if not used correctly.

So far we don't even know if the problem is a memory leak. An instant  >30x slowdown (i.e. a few iterations at <45ms followed by iterations that are (always?) 1.5s makes me think that the problem is in the code logic. However, without actually seeing the code, all bets are off. Memory leaks typically are more gradual and should be the similar in the dev. environment and as exe.

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:
There are quite a few things that can leak memory (probably incomplete):

---

... if not used correctly.

---

Yes, of course. It could be inefficiently programmed intentional behavior .

OP's comment:

@BaSs_Garrido wrote:

...I understand that it is something that accumulates memory or something like that but I don't know how to clean everything like when the application opens

---

Makes me lean towards memory build up (not a leak, strictly speaking).

We'll see (maybe, maybe not)...