Serious performance issue with LV 7.1 Development Environment

[KileenC]

Thanks Ben. I did accidentally post my response to the other LabVIEW performance question posting. I have pasted the relevant information here:

"We have reproduced this issue here on a Pentium 4, 2 GHz, single CPU, no hyperthreading, 512 MB RAM, running Win2k SP4. Similar behavior is also noted on WinXP.

There is a workaround for the slow saving behavior. Saving via File - Save or CTRL-S is very slow when many VIs are in memory. However, if you edit a VI, close it, and then answer "Save" when prompted, it saves very quickly. You can see this as follows:

1. Open loader.vi, set it to load 1000 copies and open front panels. Run the VI.


2. Hit CTRL-N to create a new VI. Be patient.


3. Select File - Save A
   s, give it a name, and save. Once you click save it takes 10 - 15 seconds on my PC


4. Drop a numeric constant on the diagram. Hit CTRL-S. This took another 15 - 20 seconds on my PC.


5. Drop another numeric constant on the diagram. Close the VI, and when prompted, click Save. The VI saves and closes very quickly.

R&D will continue to investigate the performance behavior. Thanks again!


Kileen C."

[jdunham]

Of course, LabVIEW doesn't auto-save, so an experienced user (one who has lost data in the past) will save every minute or so. Closing and reopening so often wouldn't save any time.

[dhedges]

I have been able to reproduce this behavior on Windows XP, but only if the panels are opened. I have loaded a system of 2500+ VIs through the VI server, but if the panel windows are closed (not just minimized) then I don't get any sluggish behavior. If the panels are loaded but not visible, then there is no penalty. Hundreds of windows have to be open to see the problem.

I think the problem I'm seeing is not that LabVIEW is slow, but rather Windows is doing inefficient or unnecessary calculations, probably trying to draw the taskbar with hundreds of buttons. When I look at the task manager, the CPU usage is high, but not in the LabVIEW process -- it's Windows Explorer that's busy.

That might explain the reason why hitting the run button takes so long
. When you do, the title of the window changes, which hits a bottleneck in the OS. The same rationale could explain the save penalty.

But from your description, it sounds like your "giant" VI is one of only a handful of windows open. This doesn't jive with what I'm seeing. So, am I wrong? How many windows do you have open?

If, for some reason, you have hundreds of windows open, then did you try the same system in LabVIEW 6.1?

[Rob_Calhoun]

I have found the problem occurs even when very few windows are open. When I did my test, the "giant" VI had no controls and exactly one subVI with about 1200 subVIs (all closed) below it. The "giant" and the menu show/hide VI were the only open windows. I have not tried opening the code under Windows XP; I will try that when I have access to an appropriate machine. I would be interested to see if you see a of memory churn under XP (use task manager, processes + view menu to watch the number of page faults as you execute the program with and without your large project loaded.)

I can't try the exact same test in Labview 6.1 because NI decided to drop support for Labview 6.1 file format in Labview 7.1. Since I don't own 7.0 (which can save as 6.1), I ca
n't go back. That's why I keep hoping NI will fix this.