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! 

[PrimaryKey]

Does seperating the compiled code from project elements help here? Does minimizing the compiler optimizations to improve enviroment responsivenes help?

[dthor]

@RacenBlack:

When I switched to 2012, the first thing I did was reduce compiler optimization. I think I may have also seperated compiled code, but I can't remember (and can't check right now). I have not seen a timeout on the class editor since, but I can't say with 100% certainty that changing the compiler optimization or sererating compiled code caused it to work better.

So the short answer to your question is: maybe.

[fabric]

---

@RavenBlack wrote:

Does separating the compiled code from project elements help here? Does minimizing the compiler optimizations to improve environment responsiveness help?

---

I don't think that separating compiled code helps... I have had all my compiled code separated for around two years now and I never noticed any improvement with respect to class-related slowdowns.

Compiler optimisations are something that I have (still) not really played with. I just turned my optimisations down to zero... I'll post back here if I notice anything significant in the coming weeks.

But let's turn this around: You have a blue icon, and you are the first of your kind to contribute to this discussion . *Should* I see improvements in projects with large amounts of cross-linking and dependency complexity if I reduce compiler optimisations?? As always, good inside knowledge is most welcome here!

[Lee_Denaro]

I have an class creator I am getting ready for the tools network that does this for new classes. I always hated only having the option to define the name at creation and having to go into the properties dialog box (which for some reason takes forever to load) everytime I make a class. I have it set up to live in my "Tools" project menu, but it would be sweet to have it be the right click option as well

Heres a screenshot, hopefully its up soon (for free of course)!

[dthor]

So Lee_Denaro, this utility that you're making allows the programmer to set all (or most) of the class properties before making the class? Cool! I look forward to it.

[Yamaeda]

If you install G# you'll get a nice r-click menu in the project environment and possibility to select parent class, not to mention reference based objects.

The project still gets sluggish as mentioned above though, as it's LV classes in a project environment.

/Y

[bela.komoroczy]

I have to agree totally with this idea!

We have a project with about 100+ classes and 3000+ VIs. It is based on AF, using only dependency injection for sending messages, but the growing number of message classes made us to get rid of unique message classes for each message. Editing a class' private data took 5-15 minutes, depending on - maybe - how deep it was in the inheritance tree.

Now we have ony one message class with variant input, and the project is still painfull... but it is managable...

But this workaround brought extra message routing code, problems to follow who send what to who. So having many classes in a project is a problem, and it is not always justifiable why it needs to take so long for the IDE to be responsive again.

Now for a new project I am thinking aout using as few classes as possible. DQMH "objects" seem to be a good choice, however I am still not sure what to do.

Using classes is sooooo nice, would hate to forget it.

[wiebe@CARYA]

The number of classes probably isn't the only factor. I have 308 classes, ~3000 VIs. Although changing private data is slow, it's not 5-10 minutes. More like 15 seconds.

So there must be other factors causing the lag. Maybe coupling? I'd say AF would cause a higher coupling (compared to not AF)?