LabVIEW occasionally very slow to save

[Thoric]

Hi all,

I'm using LabVIEW 8.5.1 on XP Pro. Most of the time I have no problems saving my project, but occasionally when I wish to save the main vi of my project LabVIEW takes well over 10 minutes to respond. There seems to be no pattern to when or why it will sometimes take less than a second, and sometimes a good quarter of an hour. Anyone else come across this oddity before?

Anyone have a clue how to stop it from happening?

Cheers,

Thoric

More inf: The main project vi isn't exactly large, encompassing only a simple queued state machine with a 40-odd case event structure, and a front panel tab control with a fair few controls and graphs on it. The project overall is approx' 40 subvi's in size. I use source control, with Microsoft SourceSafe. My Windows installation has all the updates.

[Broken_Arrow]

You may have a memory leak. Reboot the computer, open your project and run your VI(s) for just a minute or so, being sure to access all parts of your system (i.e. allow all of the VI's a chance to run a few times) then shut down. If that reliably works fast, then you might suspect a leak. Your queue can cause memory issues (not really a "leak" per se) if you're not careful how you use them in a loop, and in your case, a fairly long state machine.

Message Edited by Broken Arrow on 06-11-2008 08:54 AM

[Thoric]

Thanks for the advice Richard

Saving certainly works fine in the early morning, after only a couple of hours of working. It's more towards the afternoon that things start getting hairy.
If it was a memory leak, would the process Mem Usage in Windows Task Manager show anything of note? Watching the Mem Usage of LabVIEW doesn't show any rapid/slow increase in RAM allocation at any particular time when saving, but that's not conclusive of course.
Also, should any memory allocated to the queue not be cleaned up after the vi stops?

Thoric

[Broken_Arrow]

Assuming you don't run a Real-Time system, then you can just use Task Manager's Performance tab and obverve the "PF Usage" over a few hours. I have tracked down several leaks with this. Just keep in mind that the PF Usage reports in MB's, so give it some time.

Regarding your question about the Queue, you should "read out" your Queue and destroy it upon leaving the VI, regardless of what you expect the bahaviour to be when the VI is stopped.

Message Edited by Broken Arrow on 06-11-2008 09:00 AM

[Thoric]

Yes, I have noticed memory leaks in the past, more specifically with the older versions of IMAQ and image compression utils, by monitoring the memory allocation (rather than Page File allocation) of LabVIEW.
I most certainly do close my queues (and everything else) in a 'termination' sequence frame, although I don't ever 'read out' the queue as I always presumed closing the queue would delete the entries, and hence release any allocated RAM.

Thoric


Message Edited by Thoric on 06-11-2008 03:12 PM

[Broken_Arrow]

Yeah, destroying the Queue is good enough.

Of the last four systems I've dealt with, memory leaks were an issue. One was just bad programming (building arrays in loops in a 24-7 program) and the others were LabVIEW bugs and an odd deal where wiring the error input on a Notifier caused memory to build if the error cluster had data in it, such as a warning but not an outright error.

[Thoric]

(destroying the queue) Good

(memory leaks) Hmm, not so reassuring to learn that LabVIEW still has so many bugs in it. Memory leaks can be an expensive issue to isolate and find a workaround for. It can take a lot of time to do. How long before release 8.5.2 !?