Strange memory issue

[Mark_Yedinak]

It interfaces with an external device over Modbus TCP. However in this instance for my pre-release testing there is a simulator running on the same machine which handles the device end of the communications. The simulator appears to be running normally and there should be very little latency since all traffic is limited to the single computer.

[santo_13]

---

@Mark_Yedinak wrote:

It interfaces with an external device over Modbus TCP. However in this instance for my pre-release testing there is a simulator running on the same machine which handles the device end of the communications. The simulator appears to be running normally and there should be very little latency since all traffic is limited to the single computer.

---

Since it is TCP, I wonder if any Firewall or new Antivirus policies affect your traffic.

[Mark_Yedinak]

Yet another mystery. Apparently one has to clear the compiled cache dozens of times. After clearing it again this morning everything is running normally again.

[Mark_Yedinak]

Crap. After running the application a few times I am right back to the performance issue again. This is extremely frustrating.

[alexderjuengere]

---

@Mark_Yedinak wrote:

I have a rather large application [...]

Does anyone have any thoughts on I might be able to narrow down where the issue is coming from?

---

- do you have full compiler optimization in all the .vis of your project?

- for each .vi:  have you forced a compile before saving via
Windows / UNIX: <Ctrl> + <Shift> + Run Button?

[alexderjuengere]

---

@Mark_Yedinak wrote:

The code is currently running LV 2018. I also have LV 2023. This issue did appear to show up after I ran a repair which ended up updating stuff. I would like to avoid having to uninstall everything because I have several versions of LabVIEW installed and I need those multiple versions. The application does log the memory usage to a DB but for some reason the call to get the memory usage is not working in LabVIEW 2023 64-bit.

---

I try to keep only one or two versions of labview installed on a computer, where I have to build .exe, as it has been reported, that many version of labview installed can "cause issues". those issues are hard to reproduce, when trying to re-create them. re-installing the operating system and labview  may solve your issues.

[Mark_Yedinak]

---

@alexderjuengere wrote:

---

@Mark_Yedinak wrote:

I have a rather large application [...]

Does anyone have any thoughts on I might be able to narrow down where the issue is coming from?

---

- do you have full compiler optimization in all the .vis of your project?

- for each .vi:  have you forced a compile before saving via
Windows / UNIX: <Ctrl> + <Shift> + Run Button?

---

The application is over 4000 VIs. Forced compiling on each VI would take some time. I have repeatedly cleared the compiled cache which should accomplish the same thing.

[Intaris]

Instead of clearing the compile cache, I sometimes just rename the top-level folder. Does the same thing, LV needs to make new compiled code for the new path.

Clearing of the compile cache should allow us far more choice what to delete. Just offering an "all or nothing" option is very frustrating when using multiple projects.

See HERE. Wow, 9 years old already.

[Spruce]

My go to procedure for anything weird is to clear the cache then do a mass compile. The project must be closed for the mass compile to work properly.

I also do this after modifying any typedef that is used in a large number of VIs as the environment can become very sluggish.

I doubt that clearing the cache before the mass compile is necessary, but hey, it only takes a few seconds.

[alexderjuengere]

---

@Mark_Yedinak wrote:

---

---

The application is over 4000 VIs. Forced compiling on each VI would take some time. I have repeatedly cleared the compiled cache which should accomplish the same thing.

---

do you have vis in that project with a compiled-code-complexity bigger than 9 or 10?

then, the vi is only partially optimised