09-24-2019 03:13 PM
Hi all,
I have been making a program that uses a 3D graph to plot and display data from a 3-axis accelerometer. The program works great! However I noticed in my windows task manager that the LabVIEW.exe is slowly growing in size while my program is running.
I've managed to isolate the problem and create a snippet of it attached below:
It looks to me like constantly updating the position of the cursor is causing the problem. I've noticed that updating the cursor position seems to take a long time when compared to the time it takes to update the plots of the graph. It also seems processor intensive. When I let the attached snippet run on my Windows 7 machine I see a growth of 4-8 megabytes a minute. I do not get the memory back until I close LabVIEW entirely. I am using LabVIEW 2018 SP1 64-bit.
I have come here to ask:
09-24-2019 10:47 PM - edited 09-24-2019 10:48 PM
Hi,
This is merely a suggestion, you don't need to clear ref in every iteration, try using a shift register to store 3D graph reference and move Clear Reference function out of the while loop, it should reduce some execution time..
09-25-2019 10:38 AM
Thank you for the suggestion. I will remember that going forward.
09-25-2019 10:43 AM
@Nochenon233 wrote:
Hi,
This is merely a suggestion, you don't need to clear ref in every iteration, try using a shift register to store 3D graph reference and move Clear Reference function out of the while loop, it should reduce some execution time..
You don't have to close that reference at all, actually:
http://www.ni.com/tutorial/14393/en/
I believe the Close Reference in this code is a no-op, though it might be a bug causing the memory leak.
09-25-2019 11:20 AM
@JustTheChip wrote:
It looks to me like constantly updating the position of the cursor is causing the problem.
I see the same thing in LabVIEW 2019 even after cleaning up the code significantly (picture). This is something NI should look into. (Yes, none of your references need to be closed, setting the cursor active and visible needs to be done only once, etc.)
Of course do you really need to change the cursor 1000x/second? The reponsse time of your retina is significantly slower! Seems excessive, especially since it probably needs to switch to the UI thread doing so.
09-25-2019 12:12 PM
1000 updates a second was only done in this snippet to exaggerate the problem.
In my program, the cursor updates are event based and normally update only once every couple of seconds. Despite a significantly lower update rate, I still see quite a bit of growth in my program.
When I was troubleshooting this problem in my program, I experimented with long dwell times between cursor updates. The growth would eventually stop if I quit updating the cursors, however I would see about 2 megs of growth per every single update, regardless of dwell time. The growth would occur over the course of a minute or two, and then stop until the next time I updated the cursor.