Slow LabView 2016 IDE

[Hooovahh]

---

@crossrulz wrote:

Besides, your SCC should keep track of all of your changes and you should document in the SCC what you changed where.

---

I agree with the SCC comment, but it isn't always obvious what things have been tried by looking at the change log.  Like for instance there are plenty of times I will throw together some code that works but probably isn't very efficient.  So I will then disable the code and re-write it in the enabled case.  I will then leave a bookmark of #Alternate which shows doing (what I believe is) the same work but in a different way.  Then I can evaluate it later on if one or the other is better, or if the new code I wrote isn't actually equivalent and there is some edge case I didn't think about that he original handled better.  Then it is easy to just enable the older case and see the difference.  If this were in SCC the comment might say optimized some part of code, or it might say something unrelated.  Having the #Alternate tag is an easy thing to look for and evaluate in a code review.  I don't do it too often but I'm now starting to question how many disable structures I have in my code.

@Ben wrote:

Does removing comments count as code development or destruction?.

---

Depends am I getting paid by the line of code graphical object?

[ChrisStrykesAgain · Accepted solution]

---

@EWiebe wrote:

I think, I have found the solution / reason:

Digram Disable Structure (s)

After removing all Digram Disable Structures from my whole code (main VI and SUB-VIs), the IDE is now fast again. Now it needs ~7 seconds to connect / disconnect wires (this is relatively fast).

(I thought the diagram disable structure does not matter because the compiler will completely ignore it and used it frequently, but as I can see now, it does matter...)

Thanks to all who investigated time to help me !!!

BR

---

Eugen,

I'm one of the LabVIEW Product Support Engineers with the LabVIEW R&D team, and I took a look at your SR. After downloading the code, I had a senior developer look at this, and I think we were able to narrow in on the root cause in a bit more detail. To be clear, it is /not/ a direct function of the diagram disable structures. In and of themselves they are innocuous.

What you are actually seeing is the result of a change in the way we handled type propagation in 2016. (For those not familiar, this what we call the process we go through when we make sure all of the connected wires are of compatible types.) In this specific case, we altered the typeprop algorithm, specifically the way we handle upcasting classes, in a manner that had unintended side effects and, in this case, led to a performance degradation over previous years.

I'm guessing that deleting the diagram disable structures alleviated the issue because there was simply *less code* that required typeprop afterward. I didn't analyze your code in absolute detail, but I didn't see a ton of code in diagram disable structures. My best guess is that one of the subVIs you had disabled was inlined or otherwise significantly increased code complexity (and by extension, typeprop time). I would be interested to know what your final VI complexity is listed as once the diagram disable structures are removed. 

I filed CAR 638772 regarding this behavior and anticipate we will explore reexamining our typeprop algorithm for future releases, as well as considering including related fixes in future patches for previous versions. I would recommend monitoring the Bug Fix Lists and Patch Details Documents of upcoming releases for the CAR number mentioned, or, alternatively, watch for notes that mention type propagation. 

[Yamaeda]

Now this is interesting! I opened the same project on this computer and it's snapping fast! The CPU specs are simillar, but on the ordinary one it's running in a virtual machine from a mechanical disc, on a domain computer without network connection. I can understand that it's somewhat slower on the virtual machine, but not a factor 1000x?! (It really is that big, here VIs open instantly, like 0.1sec, and it can easily be 100 secs on the other one.

If it is type propagation, would that require network?

I really don't understand.

/Y

[EWiebe]

Seems to be solveld now in LV2016 Patch 5:

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

search for "638772"

Thanks to NI !

[ChrisStrykesAgain]

627910 should also give a nice little boost in some cases. There are further changes in 2017 and some others targeted to future versions that should also help with editor responsiveness for large projects.

Worth noting, 2016 f5 was released after 2017 shipped, so 638772 isn't actually in 2017; it may be in a subsequent 2017 patch but I can't speak definitively.

[MrQuestion]

I know that this is an older thread, but I do have have a suggestion that will blow away a few people that are still having performance issues.

Some companies; especially larger companies, will place "My Documents" and other folders on a network drive.

IT departments will do this in the background of your computer. Most people would never know, or care. 

For IT departments this has several advantages. If you log into one computer everything in your "my documents" is carried with you on login, also everything is backed up.

Unfortunately LabVIEW uses several folders in "My Documents". It is a very busy folder in the NI world. LabVIEW gets unhappy if it has to wait for read and writes from a laggy network share.

If you happen to be working with a company that does this transparently you will have serious performance issues.

You will also have stability issues if you have LabVIEW installed on different machines, because LabVIEW on both machines will be accessing the same data folders in the network shared drive.

You will have data contingency, and more than likely one of your LabVIEW instances will just randomly crash.

The best thing you can do is to manually set your "My Documents" folder to offline. The process to do this is different for windows 10, 8 and 7. But that is assuming that your IT Security Policy will allow this. (From my experience most will allow you to have a offline folder till next login where the setting is reset and the "My Documents" are re-synced. 

You can also go to LabVIEW settings as seen in the image and change your paths to a local hard drive. (Some companies do magic to windows to trick the system into thinking that the "My Documents" is local when it really isn't!!! Don't pick another folder path in any Windows default folder, this includes the "Desktop". Best thing to do is create "c:\LabVIEWStuffFolder\Data")

If you change the LabVIEW Paths that will help with about 98% of the the issues. There are some parts within LabVIEW that does not listen to that setting and will place stuff into "My Documents" anyways. 

Another thing people can attempt would be to just unplug the ethernet cable or turn off the wifi. Windows will automatically turn all system folders that are being network shared to offline mode.

I have also had issues with network monitoring software.

I worked with one client where LabVIEW would just crash randomly about every 5 or 15 minutes.

Found out that the issue was related to the system doing a screen capture for the network security.  (yes, that is correct!!! Some companies go so far as to take screen captures in the background. This practice seems to be becoming more common)

Disconnecting from the network might help troubleshoot this issue as well.

~~Good luck

[paul.r]

It may not have been the cause in this case, but more often than not this is caused by circular dependencies. 

[Rick_J.]

I realize this is an old thread but I was searching for help on this same subject and found my way here.

I thought I'd offer something I found regarding slow editor response in the LabVIEW IDE:  If you have the Navigation  window open my editor gets real sluggish with large VIs.

If the large VI is open but I'm editing a smaller VI with the Navigation window open there's not much lag, but as soon as the large VI is shown in the Navigation window the editor slows dramatically.

[billko]

Yeowza - I'm going to say you should never have to use the navigation window to navigate a VI!  (Not your VIs anyway.  I hate working with those "Uber-VIs" that what I have to call LabVIEW hacks come up with.)  😉

[RavensFan]

I'm surprised in this long thread that a comment about that navigation window didn't come up before now.  (Though I didn't read the original thread to see if the slowness was found to be cause by something else.)

Yes, when a navigation window is open, every change in the VI is going to cause a redraw in the navigation window which will be slow because of the large amount of entities that make up the VI, like if you are nudging nodes around.

In those Uber VI's, open the navigation window so you can select the part of the VI you want to make visible, then close it before working on the VI so the slow redraws won't be a problem.  Do that until you've refactored the VI to the point that the VI doesn't take dozens of screens anymore.