Takes too much time during editing labVIEW VI code

[_Bryan]

I had a similar problem in LabVIEW 2011 when I had the maximum undo steps set to 99.  I changed it to 10 and everything seemed to work much better.  It could not hurt to try and see if it helps.

[Bob_Schor]

---

@_Bryan wrote:

I had a similar problem in LabVIEW 2011 when I had the maximum undo steps set to 99.  I changed it to 10 and everything seemed to work much better.  It could not hurt to try and see if it helps.

---

I didn't think of looking at that, but when I did, my LabVIEW 2016 (a) does not separate Compiled Code from new files, and (b) has maximum undo steps in each VI set to 99.  I believe these are the defaults, and I have a very responsive system.  I think this is due to the number of "elements" (functions + wires) in my Block Diagrams -- the count is relatively low (compared to some Block Diagrams I've seen posted on the Forums).

Bob Schor

[Hooovahh]

2016 definitely had some issues with thinking code needed to be recompiled when it didn't, causing additional slow down.  I had a project from 2015 up save to 2016 when it came out, and eventually back saved to 2015 because it just took way too long to do stuff like save.  There was a thread on disabling Live Drag since that was released in 2016, but I don't think that helped.  My project size is around 3000 VIs or so.  I would open the project, do a Save all, then close, re-open, move a single block diagram object on a single VI and now a Save All would take a minute or so for that single VI.  I eventually went to 2017 and it got better, but 2018 is worlds better and I'm upgrading all of my large projects to that.

Things can make this worst, and it isn't just a "2016 sucks" kinda thing.  Circular dependencies, compiled code, inlineing, mutation history, disabled diagram structure, missing dependencies, and other factors can make things worst.  Sorry I don't have any advice, but at least you aren't crazy in my opinion.  If you can isolate it and reproduce the issue on a project I'd contact NI for support and see if they can help.

[Michael_Munroe]

I just loaded a large project saved in LV2012 with over 1500 VIs and 70 classes into LV 16.0f5 and had no problems editing VIs.  Even dragging large blocks with livewire enabled moved smoothly.  After pressing Save All, the responsiveness only was slightly worse.

Your issue may be with your PC:

• Use task manager to check memory usage. Look for background programs slowing the PC.
• Check disk utilization. External devices might be accessing your PC
• Check your file syncing.  I have dropbox, onedrive and google drive all running

Your issue may be with your code:

• Use VI Analyzer to check your project.  It might find something you don't see.
• Look at your project in Files View.  There might be files on a network drive.

Your issue may be with LabVIEW

• Delete LabVIEW.ini next to LabVIEW.exe and reopen LV.  Something in your settings could be bad.

[antony.g]

I was reading this thread with interest as I have found LabVIEW 2017 incredibly slow recently. I have put this down to the following:

1) The Laptop I am using in a high spec quad core I7, 8GB RAM, high end graphics card, but with a fresh copy of Windows 10. It has been constantly installing Windows updates since I received it.

2) The virus checker installed (McAfee) appeared to be performing a full virus scan which took days to complete.

3) The home directory was mapped to a network drive. The default data drive was set to the same network drive.

The PC has slowly sped up over a couple of weeks, the virus checker is quieter, and most of the Windows updates are installed. I changed the default data drive to the local hard drive. Finally LabVIEW appears to run at a half decent speed. I did however notice that screen redraws are much slower than older versions of LabVIEW, dragging items around in LabVIEW appears slow, and screen redraws in TestStand are incredibly slow still.

Overall I believe that LabVIEW 2011 running on Windows 7 was much faster (on the same laptop). I am tempted to revert to an older version of LabVIEW, and maybe go back to Windows 7 or Linux. If I switch to Linux then I will write my own test executive in LabVIEW, I have always found compiled LabVIEW to be much faster than TestStand.

Any opinions? Does anyone else see these sorts of problems? Maybe all these problems are just down to a badly configured laptop by our IT department.

[billko]

---

@antony.g wrote:

I was reading this thread with interest as I have found LabVIEW 2017 incredibly slow recently. I have put this down to the following:

1) The Laptop I am using in a high spec quad core I7, 8GB RAM, high end graphics card, but with a fresh copy of Windows 10. It has been constantly installing Windows updates since I received it.

2) The virus checker installed (McAfee) appeared to be performing a full virus scan which took days to complete.

3) The home directory was mapped to a network drive. The default data drive was set to the same network drive.

The PC has slowly sped up over a couple of weeks, the virus checker is quieter, and most of the Windows updates are installed. I changed the default data drive to the local hard drive. Finally LabVIEW appears to run at a half decent speed. I did however notice that screen redraws are much slower than older versions of LabVIEW, dragging items around in LabVIEW appears slow, and screen redraws in TestStand are incredibly slow still.

Overall I believe that LabVIEW 2011 running on Windows 7 was much faster (on the same laptop). I am tempted to revert to an older version of LabVIEW, and maybe go back to Windows 7 or Linux. If I switch to Linux then I will write my own test executive in LabVIEW, I have always found compiled LabVIEW to be much faster than TestStand.

Any opinions? Does anyone else see these sorts of problems? Maybe all these problems are just down to a badly configured laptop by our IT department.

---

This makes sense, as most antivirus packages will check files over the network as they are being accessed either for the first time, or the file has changed since the last scan.

[Intaris]

Oh lord, yes, make sure your compiled cache isn't on a network drive, that will utterly destroy your performance...

If possible, buy a fast SSD and put your "LabVIEW Data" folder on it.

[SKant]

Thank you Michel and thank you all member for providing me valuable suggestion to resolve my issue.

I found that my main VI taking much time for editing and save. I had tried all the scenario which you guys suggested and then I have updated labVIEW patch with LVf6 patch and around 60% performance got improved (mostly editing vi). But still while saving main VI, its taking around 15-30 min time. 

It seems that LabVIEW 2016 f4 patch having issue. They have fixed most of the issue on LabVIEW 2016 f5 and f6 patch. 

http://www.ni.com/product-documentation/53294/en/