Slow LabView 2016 IDE

[EWiebe]

I don't have LV2015 installed here (stepped from LV2014 to LV2016).

[EWiebe · Accepted solution]

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

[Ben]

That is great and troubling news Eugen!

On the one hand it is nice to learn that you found a solution, on the other hand, removing diagram disables is a puzzle piece that I can not fit into the model of LV as I know it. I would have thought removing them would make things worse and going farther... I would think that using diagram disables to starting throwing away code could be a valid technique.

Now about your diagram disables...

What did you have in the "enabled" states?

The "use default" setting for the error cluster implies there was nothing there.

How many diagram disables did you have and had to remove?

Trying to put the puzzle pieces tighter without resorting to using a razor blade to trim them...

Ben

[EWiebe]

* the enable states were (in the most cases) empty. I used the "disable diagram structures" to keep code and code snippets in near place ... (hunter and collector/gatherer) ...

* I hat a lot of such disabled structures (~100), some were small (e.g. one subvi), some were bigger (code snippets)

[Ben]

---

@EWiebe wrote:

* the enable states were (in the most cases) empty. I used the "disable diagram structures" to keep code and code snippets in near place ... (hunter and collector/gatherer) ...

* I hat a lot of such disabled structures (~100), some were small (e.g. one subvi), some were bigger (code snippets)

---

In my early days of coding I was taught to never delete code but rather comment it out if not longer used. That makes it easier to undo changes if they hurt things and also serves as record of what it used to be like... good or bad. So I can relate to the keeping code around in DD structures. But your observations now make me rethink that philosophy.

Thank you so much for sharing!

Ben

[crossrulz]

Diagram Disable Structures do create sequence boundaries, which could increase the code complexity.  If they are not connected to anything, then I would expect them to be removed from the compilation, but that is still work the compiler must do.

---

Ben wrote:

---

In my early days of coding I was taught to never delete code but rather comment it out if not longer used. That makes it easier to undo changes if they hurt things and also serves as record of what it used to be like... good or bad. So I can relate to the keeping code around in DD structures. But your observations now make me rethink that philosophy.

---

That philosophy made a lot of sense in a text language.  I found it very distracting in the graphical format and added confusion.  Even in my C++ days, I actually spent half of my time in one project removing all of those comments because they were more than the actual code (seriously cut the code base in half) and we kept making changes to the comments instead of the real code (eventually became very hard to distinguish the real versus removed code).  Besides, your SCC should keep track of all of your changes and you should document in the SCC what you changed where.

[Norbert_B]

I think that the diagram disable structures do hurt in some ways.

1. VI size on disk: Each component on the BD requires some bits&bytes for the BD within the VI
2. Loading of VI in DevEnv: When loading a VI, LV loads also its dependencies, most likely subVIs (and ctls). Afaik this is also true for disable structures for ALL disabled cases in the DevEnv. That does not mean that the subVIs are called by the compiled code, however, the DevEnv already has all subVIs loaded and knows if they are broken. I think this is the reason for the slow down
3. Even though the disabled cases are not compiled for the VI, they still seem to undergo a sanity check and some kind of pre-compilation. Otherwise, they wouldn't show broken wires and such
4. SubVIs called in disabled cases still remain in the VI Hierarchy. This can lead to unexpected behavior

Personally, i consider the disable structure to be a good measure for debugging and specific development steps. However, i am used to remove all disable structures when finalizing the project to keep the code tight and easy to read (as far as possible).

[Yamaeda]

That's awesome to hear! I do know have have quite a few of those in my slow project also. I also remember having issues with property nodes in the disabled case some 8 years ago, they broke my code, indicating they weren't completely ignored (but only in a select few instances). But that was LV8.2 ...

I'll make sure to clear out some to test on the next occasion on that project.

/Y

[Yamaeda]

Follow up question: Do you also suffer from random Window shuffling when this happens, and did that also improve?

/Y

[Ben]

---

@crossrulz wrote:

... Even in my C++ days, I actually spent half of my time in one project removing all of those comments because they were more than the actual code (seriously cut the code base in half) and we kept making changes to the comments instead of the real code (eventually became very hard to distinguish the real versus removed code). ...

---

C-Story Time !

Spoiler

Before I learned about G...

When I went to college I had already been developing C for quite a while but had never met anyone that understood C. I had just read the Kerningham and Ritchie book and taught myself. One of my early course in college was a class for programming in "C" so I was excited to get my code reviewed and learn something from someone that knew C.

Learning something... hmmm....

The professor could not get the interface to work using C++ and I helped him get it going. I then developed the application to control the movement of a gantry crane. It turns out mine was the only code that worked.

When sitting down with the T/A for my long awaited code review the only feedback I got was "TOO many comments! It was hard to find the actual code."

Being one that started with machine and macro coding, I always started with the comments and would latter return to adding the code. That left me with about a 3-5 to one ratio of lines of comments to lines of code.

So...

Does removing comments count as code development or destruction?

Smiley-wink)

Ben