Improve IDE performance when working with lots of classes

[fabric]

Classes? OOP? ... Huh?

Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!

The problem:

Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.

Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:

• Opening the "class properties" window takes 10 seconds or more
• Renaming a class brings the editor to a standstill

For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!

Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.

The idea:

Improve the responsiveness of the LV editor when working with classes.

• Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
• Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
• Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!

Credits:

Others have written about this topic well before me. Here are a few relevant discussions:

• http://lavag.org/topic/15199-editing-an-existing-class/
• https://decibel.ni.com/content/thread/14907?start=15&tstart=0

Feel free to link more! 

[Daklu]

I kudoed the idea because it is a concern, but I'm not convinced the slowdown is due to the number of classes or the size of the inheritance tree.  Based on my experience it appears to be more related to the complexity of the dependency tree.

[fabric]

"...because it is a concern"

You use classes as much as the next guy, and you have quite the reputation for good architecture.  I'm curious to know how "the slowdown" affects your work...

"Based on my experience it appears to be more related to the complexity of the dependency tree."

That may be closer to the root cause of the issue, or at least to some of the symptoms such as small edits causing extensive CPU grinding. In any case a deep inheritance tree or many nested libraries will almost certainly add complexity to the dependency tree.

On the other side of the coin, it is difficult for me to understand why the load time of the "class properties" dialog should be driven by *dependencies* per se. It seems that the inheritance tree should be one of the main factors there... (I'd love to get some inside information on this!)

[dthor]

First of all, I'd like to say "YAY!" that my idea was linked. 

>Opening the "class properties" window takes 10 seconds or more

One of my projects has about 40 classes, and sometimes the "class properties" window takes so long to open that it times out, and thus doesn't open. 

>Based on my experience it appears to be more related to the complexity of the dependency tree.

The same project I mentioned above has a very linear tree: only two classes have multiple same-level children (one of which has about 30 children). So that's my counter-argument. I don't think it invalidates your point though.

I do think that one of the roadblocks to widespread class usage is the editor slowdown. I know that when I make a new (small) project, I want to use classes, but then I give up rather quickly because it's faster and less of a hassle for me to make non-OOP code.

[FabiolaDelaCueva]

I have also experienced that having classes nestes inside lvlibs make matters worse. In one of my projects I had to resort to disinheriting a class and moving it outside the library in order to edit it, then I inherit it again and move it back into the library. 

This is a hasle, but it has been the only way I have found out for the IDE not to halt when I am trying to change the private data of my class and modify the property node-accessors. 

Some people have suggested to not put my classes inside .lvlibs, but I like so much the project organization and the advantage of having reusable code together, that I can not bring myself to do that.

I hope this idea gets a lot more votes.

[GabbyG]

I use mostly refrerence based classes (G#) so there is no real need to put them into lvlibs. (Well, I don't). It is always easy to create a new instance.

And on my new Ivy-Bridge I have not yet found any severe delays.

It's probably one of these old laws that says, software complexity grows to fill the limits of hardware. Right now I am on the good side.

Gabi

[Intaris]

I'm getting regular problems with accessor VIs not synching with property nodes in code and giving nice crashes or wqeird messages (Dynamic VI cannot be executed because the member VI cannot be found!).

The class editing can certainly be more robust.  Also finding the source of errors is sometimes hard.  Not knowing where exactly the problem is can waste a lot of time.

[fabric]

Argh... Just experienced the dreaded "timeout while opening class properties" feature. (@dthor: I feel your pain!)

Even if nothing else was improved, surely the timeout should be set to more than one minute... Then at least I could get up and grab a drink while I wait! 

Current limitations mean that I come back from the fridge to be greeted by an error message, then have to close my very-large-project, then modify my inheritance tree in a temporary-sandpit-project, then reopen my very-large-project.  I could have better spent those 5 minutes posting ideas on the idea exchange!

[fabric]

100 kudos and counting! 

Any comment from NI R&D as to whether there is anything in the pipes that might help here?

[JackDunaway]

fabric well-characterizes the threshold of pain at 10sec+, but the threshold of interruption occurs long before this.

That's when the delay is noticeable enough to interrupt cognition or programming tasks whilst grooving along.

Here's a 12sec video clip of the delay when deleting a node then hitting CTRL+Z; this delay occurs on a wide range of essential programming tasks:

(apologies for the annoying, persistent toolbar on this video)

[fabric]

One more programming task that seems to take far too long in a big project:

• I have a bunch of tiny classes in a library (e.g. Actor Framework messages)
• I need to add a new class to the library that is almost identical to an existing one, so I "Right-click>Save As>Copy" to make a clone
• Did I mention that the classes are tiny? A typical example contains no class private data and only one or two methods (which are generally just wrappers)
• I then wait over a minute for LV to figure out how to clone my tiny class...

Why? Presumably this is related to some kind of re-evaluation of the inheritance tree caused by adding a new class.

Irrespective of the cause, does anyone have any ideas for how to what to do with all these one-minute-chunks-of-time that I keep wasting? The current situation is that as my project get bigger, I tend to snack more!