LabVIEW 2009 slow editing

[nonecure]

 Ever since I switch from 8.6 to 2009 sp1, the same project has been very slow to edit.  Yes it is large, but the machine is large.  I have timed the how long I get the hour glass and how often, and the average delay is 22.5 seconds every 321 seconds.  This is driving me nuts to wait that long every 5 minutes. 

I have a quad core PC, so that should not be an issue.  I’m sure some of you could find some improvements in the code, but the code is not that bad.  I have read that they made changes to the compiler, but that should not effected an edit should it?

Thanks,

Doug

[nonecure]

I found some articles that mention 2009 compiling the code during the save and some of the problems with larger code.  Since my auto save is set at 5 minutes, this makes perfect sense.  It looks like I have 2 options:

I can set the auto save to a longer period of time.

I just tried 2010sp1 and I found that the auto save on the same main.vi has a delay of about 4 seconds.  I can handle 4 seconds over 22 seconds.  I did notice though after a hour of editing, the real save took over 2 minutes!  Any thoughts on this?

[Deborah_B]

Hello nonecure,

I would strongly suggest Mass Compiling your VIs if you haven't done it yet. Also, here's the Help file for it in LabVIEW. Does your code contain many levels of sub VIs?

Regards,

Deborah Y.

[nonecure]

Running in 2010sp1 is working much better, but it is still a little slow especially any edits effecting the front panel.  My laptop is super-fast except that it has a hard drive and not a SSD or Raid.  When monitoring my processor I notice very little CPU and memory usage but a lot of I/O activity, therefore I am questioning the hard drive speed. 

I have a few more months to finish this program and it bothers me to keep getting the hourglass.  Does anyone know how I can speed this up?

Thanks,

Doug

[Deborah_B]

Hello Doug,

Does it make any difference if you save the VI outside of the project and make edits to it as a stand-alone VI? Did you mass compile the VI's in the project? Definitely editing anything on the user interface thread takes longer but it does seem to call the hard drive speed into question. And increasing the auto-save time doesn't make any difference to how long the actual save takes, correct?

Regards,

Deborah Y.

[nonecure]

Deborah,

Thanks for your reply.  Yes I did a mass compile when I upgraded from 2009 to 2010sp1.  The wait time during auto save went down from 20+ seconds to about 3 with the upgrade, so that helps a lot.  I noticed a slight improvement when editing the main.vi outside of the project, but not by much.  Attached is the VI Metrics if that sheds any light on this subject.  I have noticed a long time ago that if I make a lot of changes it will slow up until I do a save.  This always happened even on older version of LabVIEW.

I’m just trying to better understand what computer resources LabVIEW needs for better editing performance.  I don’t see the CPU or memory usage going up, so I am curious of what is causing the slowdown.  Or more to the point if there is something I can do to speed things up (like a faster hard drive, or some kind of setting).  At boot up I have 52 processes running in the background, so that is not too bad.  We have our business Norton antivirus software loaded.

Thanks,

Doug

Dell M6500 – Intel i7 quad core processor

8 GB Ram

ATI FirePro Graphics card

320GB hard drive 7200RPM

Windows 7 64-bit

[nonecure]

I sit at less than 1% CPU usage until I do a front panel edit, then it hits ~14% usage with the hour glass.  I really don't understand this at all.

[Deborah_B]

Hello Doug,

Thank you for the VI metrics. Considering the size of the project, 259 VIs, it's not entirely unheard of for the save to take a few seconds, especially with multiple front panel controls and indicators and multiple layers of subVIs that may be present in different places in the project. Again, your laptop specs seem more than ample, but it might be useful to get rid of any unnecessary background processes or run a disk cleanup. I don't think taking the time to repair LabVIEW would cause a significant enough improvement to validate that time spent.

What actual edits are you making to the front panel? Are there control references or type definitions on these controls such that the changes need to be applied many-fold in areas of the project. Does this spike happen on every edit or just certain ones?

Here's a knowledge base article that fully explains why edit-time performance is decreased in very large VIs to boost run-time performance: LabVIEW Compiler Memory Usage and Performance. The work-around for long save times is to 'intentionally' break your VI. Hope this helps!

Thank you,

Deborah Y.

[nonecure]

Deborah, thanks for the reply.

Yes this is a very big application and I continue to try and make performance improvement on it.  At this point I think my biggest problem is the front panel.  My edits to the block diagram is not that bad, but the front panel is terrible.  The machine this runs on has a 22" touchscreeen and the front panel has 13 tabs and 20 sub-tabs with graphs, buttons, and indicators.  This is customer driven so I don't have too many options.  I try to keep the number of control references, type def's, and property nodes to a minimum.

I did notice that the longer I edit, the worse the delay gets and the amount of working memory goes up.  After a save things will get a little better, then after a few hours I need to close down LabVIEW and restart it to get my speed back.

The work-around to intentionally break your VI only helped before service pack 1.  This kept LabVIEW from compiling during an auto-save, but sp1 took care of that issue.

[Deborah_B]

Hello Doug,

I appreciate your patience on my reply, our forum notifier service went down last week. I spoke with my colleague who has been working with you on this via phone service request and was able to take a look at the code. It seems like a battle of optimizing block diagram appearance by eliminating wires vs. use of shared variables. I understand it's dependent on the customer's specs, but the extreme number of shared variables needing to be linked and updated on every save seems to be the big slowing factor here. As my colleague replied, cutting down the number of shared variables may not even save time now implementing changes after the fact on such a large program but it will yield the greatest results. Feel free to keep posting on the forums but the most efficient way to target this issue will be to work through the opened service request.

Thank you,

Deborah Y.