Labview slows down when editing

[DavidAtUVA]

First time posting here.  I have a problem with Labview suddenly taking an extreme amount of time to do anything while editing. 

Yes I searched, the problem is similar though not identical to http://forums.ni.com/ni/board/message?board.id=170&message.id=214141&view=by_date_ascending&page=1
Opening through Windows Explorer does not solve my issue.  Shared variables are not a problem.

Here are three concrete examples, though it is not at all limited to these:

Saving, no matter what the change is
Changing a property of a waveform graph (e.g. right click in Front Panel, plot, change color of line, OK)
Moving pieces on the Front Panel

These kinds of changes take on the order of minutes to do.  During the time when Labview is changing, it uses 100% CPU, program memory usage fluctuates about the beginning value +/- 2000 kb, and physical memory is relatively stable, with plenty free.  There is plenty of hard disk space free also.  When it is using 100%, it has not "taken over" the computer, i.e. I have been typing this, checking email, and other things while Labview is straining to do my simple requests. 

This has been repeated on other computers with similar results, all within the same VI.  Cannot seem to duplicate it on other VIs, either homemade or examples.

What could be going on here?  It seems to have suddenly occured as small changes have been made over the last days, and apparently it does not like one of those.  The changes made could be categorized in two ways:  cosmetic or routine changes to waveform graphs (e.g. changing plot colors, adding a derivative graph), the other group of changes reflect modifications made to load files of different types more seemlessly - these file loading changes were made to other VIs which do not experience the slowdown problem. 

Attached is a screenshot of a small portion of the VI, both the graphs and the underlying block diagram.  The file loading issue would be far more difficult to take pictures of without sending the entire VI.  The full VI file size is 1531 kb with numerous calls to subVIs.  I see comments talking about 600 something subVIs, and >10 mb files - this is far less than that, maybe 40 subVIs and all of them less than 1 mb. 


Thanks for any insight into this issue,
David

[mikeporter]

The problem is that your code is much too complex. You have a huge diagram driving a massive user interface with several tabs. You need to break the application down into modular, reusable pieces. As a point of comparison, one application I am currently working on has over 900 subVIs, the top level routine is about 240k - and it doesn't slow down at all during editing.

The tricky part of code development is to create a structurally simple application that provides arbitrarily complex functionality.

Mike...

[DavidAtUVA]

That cannot be correct.  If that were true, then simply removing the additions would make it just as fast again, but that does not work.  The implication of what you have said is that there is some threshold of complexity where, once passed, Labview no longer functions correctly.  That doesn't make sense - it would be a gradual shift towards working slower as you increase in complexity.  Additionally, the program runs just fine, fast, on < 1.7 GHz  machines with less than a gig of RAM - only editing is a problem.  In addition, we use far more complex program to automate our data collection and editing it has none of the slowdown.  The problem is something else - I do not know what, but either some obscure programming flaw has entered the code or there is an issue elsewhere. 

Thanks though,
David

[mikeporter]

Any development system can only be so resilient in the face of poorly designed code. Regardless of your other points (which are even necessarily valid) the bottom line is that your code is a problem and even if it isn't causing this particular issue, it is certainly causing others - and the flaws in it certainly aren't "obscure".

Mike...

[DavidAtUVA]

Solution was to recompile (CTRL+ALT+Run arrow).  Now all edits are perfectly fine, no problems. 

David